Pith. sign in

REVIEW 4 major objections 5 minor 34 references

Leveraging Recurrent Patterns in Graph Accelerators

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper proposes that most subgraphs of a large sparse graph share a handful of edge patterns, and that preloading those patterns into static in-memory crossbars can eliminate most rewrites during graph algorithms.

desk verdict A plausible write-reduction idea for ReRAM graph accelerators, but the BFS correctness is never checked and Algorithm 2 as printed omits the iterative frontier loop, so the headline speedups are not yet anchored. read the letter →

arxiv 2512.01193 v1 pith:2A7IUVR4 submitted 2025-12-01 cs.AR

Masoud Rahimi , Sébastien Le Beux This is my paper · ORCID
classification cs.AR
keywords graphacceleratorsReRAMcrossbarprocessing-in-memorypatternreusewritessparsegraphscircuitlifetimeBFS
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that real-world sparse graphs, once partitioned into small adjacency-matrix blocks, contain many repeated structural patterns, and that an accelerator built around this recurrence can process most subgraphs without writing to memory. If true, the energy-hungry, lifetime-limiting ReRAM writes that dominate existing accelerators mostly disappear. The authors report up to 2.38x speedup, 7.23x energy reduction, and 2x longer circuit lifetime over state-of-the-art baselines. The insight is that the high-frequency patterns are few enough to be hardwired as static engines.

What carries the argument

Pattern occurrence: after a non-overlapping sliding window partitions the adjacency matrix into C x C subgraphs, each subgraph's edge pattern is a bitmask; patterns are ranked by frequency and the top ones assigned to static engines. Static engines are preconfigured once, so subgraphs with those patterns are processed by fetching vertex data only; dynamic engines are reconfigured only for rare patterns. Single-edge patterns dominate and store a row address to skip crossbar rows.

What would settle it

Run BFS or PageRank with the proposed static-engine scheduling on a graph with high pattern diversity, such as a random graph or a synthetic graph where all 4x4 patterns are nearly equally frequent, and compare output vertex distances or ranks to a CPU reference. If results diverge, the static-pattern decomposition is unsound; if the speedup disappears, the claimed write reduction depends on the skewed pattern distribution observed in the tested datasets.

Watch

Extended reading notes

Core claim

The central claim is that pattern occurrence in a window-partitioned adjacency matrix is highly skewed: a small number of distinct 4x4 patterns cover the large majority of subgraphs, with the top 16 covering 86% of subgraphs in one studied graph. By ranking patterns and mapping the most frequent to static graph engines configured once at initialization, and keeping only the long tail of rare patterns on dynamically reconfigured engines, the accelerator avoids most ReRAM writes. The authors argue this holds across datasets for classical graph algorithms such as BFS, SSSP, and PageRank under the streaming-apply execution model, and their simulator shows normalized improvements over baseline ac

Load-bearing premise

The load-bearing premise is that processing each 4x4 subgraph as an independent inside-memory matrix-vector multiply, with static engines preconfigured to a fixed edge pattern, produces exactly the same vertex updates as a normal graph traversal for any subgraph carrying that pattern.

Editorial extensions

If this is right

  • Most subgraphs are processed on static engines with no configuration writes, shifting write activity to a small set of rare patterns.
  • Because ReRAM writes dominate energy, eliminating most writes yields up to 7.23x energy savings over one baseline and 2.3x over another.
  • Circuit lifetime roughly doubles because static engines never write after initialization and writes are concentrated on dynamic engines.
  • The architecture works with small, 1-bit crossbars (e.g., 4x4 or 8x8), avoiding the large multi-level-cell crossbars that other designs require.
  • An optimal number of static engines exists (e.g., 16 of 32 in the simulated configuration), balancing pattern coverage against parallel processing capacity.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The benefit is likely graph-dependent: graphs with near-uniform subgraph patterns, such as random or regular graphs, would see the skew collapse and the write-reduction gains shrink, leaving only preprocessing overhead.
  • The same static-pattern-reuse idea could be extended to larger window sizes or hierarchical pattern dictionaries, which the paper does not explore; that would be a natural testable next step.
  • Because the paper does not report correctness checks of BFS output against ground truth, a user should verify that the static-engine decomposition produces bit-exact vertex updates before relying on it in safety-critical graph analytics.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes a ReRAM-based graph accelerator that exploits frequent subgraph patterns to reduce crossbar reconfiguration writes. Preprocessing partitions the input graph's adjacency matrix into C×C subgraphs, ranks the resulting patterns by frequency, and pre-configures the most frequent patterns into 'static' graph engines; rarer patterns are handled by 'dynamic' engines that are reconfigured at runtime. A scheduling algorithm (Algorithm 2) processes subgraphs in batches, using a streaming-apply execution model adapted from GraphR. The evaluation is based on a custom system-level simulator and reports BFS execution time, energy, and circuit lifetime for six datasets, comparing against GraphR, SparseMEM, and TARe. Headline claims include up to 2.38× speedup, 7.23× energy savings, and 2× lifetime extension over state-of-the-art accelerators.

Significance. If the results hold, the pattern-frequency observation is a simple and potentially useful insight: because few patterns cover most subgraphs, pre-configuring static engines can substantially reduce write overhead in ReRAM accelerators. The design flow is automated and the architecture description is reasonably detailed. The paper also attempts a design-space exploration of the static/dynamic engine mix. However, the evaluation is not yet convincing. There is no correctness validation for BFS, the simulator is not released, and there is no evidence that the BFS execution is actually correct. The dataset description is internally contradictory, and the headline numbers mix different baselines. The central quantitative claims therefore rest on assumptions that are not verified in the manuscript. If the correctness gap can be closed and the evaluation clarified, the idea could be a worthwhile contribution to the graph-accelerator literature.

major comments (4)
  1. [Algorithm 2, Section III.C] Algorithm 2 does not implement BFS. BFS requires an iterative frontier propagation loop: after processing all subgraphs sharing destination vertices, newly discovered vertices must become the frontier for the next iteration. The pseudocode iterates over batches of subgraphs (Line 9) and over subgraphs in each batch (Line 10), but there is no outer loop over BFS frontier iterations or any convergence check. The text says subgraphs are 'processed over multiple iterations,' yet the pseudocode does not reflect this. Section IV reports only execution time, energy, and lifetime, and never validates BFS distances or reachability against ground truth. If the simulator executes Algorithm 2 as written, the BFS results are incorrect; if an implicit outer loop exists, it is unstated and unverified. This is load-bearing because all speedup, energy, and lifetime claims are for BFS execution.
  2. [Section IV.C, Table 4, Figure 7] The headline quantitative claims are not tied to a single baseline. The abstract reports 'up to 2.38× speedup and 7.23× energy savings compared to state-of-the-art accelerators,' while Section IV.C specifies 2.38× and 1.27× speedup over SparseMEM and TARe, respectively, and 7.23× and 2.3× energy efficiency over SparseMEM and TARe, respectively, plus 'three orders of magnitude' over GraphR. The conclusion repeats only the 1.27×/2.3× numbers. This conflation of per-baseline maxima/averages makes the central quantitative claim ambiguous. Please provide a clear per-baseline summary table or state explicitly which baseline corresponds to each reported improvement.
  3. [Section IV.A, Table 2] The dataset description is self-contradictory. Table 2 lists all graphs as 'weighted graphs,' but the text immediately after says 'since input graphs are unweighted, we use BFS as the baseline graph algorithm.' If the graphs are weighted, a 1-bit ReRAM crossbar and pattern-based adjacency matrices cannot represent edge weights, and BFS on weighted graphs requires a weight-handling strategy. If the graphs are unweighted, the table is wrong. This ambiguity undermines confidence in the experimental setup and should be resolved.
  4. [Figure 6, Section IV.C] The number of static engines N=16 is selected in Figure 6 as the point of maximum speedup on the same benchmark datasets, and all subsequent speedup and energy comparisons use this tuned N. No held-out datasets or statistical validation are provided, so the reported gains may be inflated by choosing N to fit these particular graphs. A fixed heuristic for N or a cross-validation-style sensitivity analysis would make the evaluation more convincing.
minor comments (5)
  1. [Section IV.D] The lifetime formula is garbled: the text says 'F is endurance,' but the equation shows E/(w*C) with no definition of E or a visible division sign. The formula needs to be typeset correctly and all variables defined.
  2. [Section IV.B, Figure 6] The text says 'in WS, utilizing 16 static engines achieves a 1.8× speedup,' but the dataset is abbreviated 'WG' (web-Google) in Table 2. Please fix the typo.
  3. [Algorithm 1] The text claims that when M>1, patterns assigned to static engines are 'evenly distributed across their crossbars,' but the pseudocode only labels patterns as static or dynamic; the distribution step is not shown. Either add the distribution logic to the algorithm or clarify it in the text.
  4. [Section IV.A] For TARe, the paper says 'we consider only its mapping scheme and adapt it for classical graph algorithms,' but the adaptation is not described. Without details, it is difficult to assess whether the comparison to TARe is fair.
  5. [Table 4] Energy units are inconsistent across rows (J, mJ, µJ). Use a single unit (e.g., µJ) for all entries to make the comparisons transparent.

Circularity Check

0 steps flagged · score 0.0 of 10

No material circularity: pattern reuse is a design mechanism, not a derived prediction.

full rationale

The paper makes an empirical/architectural claim rather than an analytic derivation. Pattern statistics are measured from the input graph, the static/dynamic engine split is a design choice, and reported time/energy/lifetime numbers come from a system-level simulator parameterized by external models (NVSim, CACTI, published ADC parameters). The chain 'frequent patterns -> static engines -> fewer crossbar writes -> higher speedup/energy savings/lifetime' follows from the definition of static engines as pre-configured, but the paper does not present this as an independent prediction derived from that definition; it reports simulated measurements. No self-citation is load-bearing: the streaming-apply model is adopted from the external GraphR work [10], and no uniqueness theorem or prior author result is used to force the architecture. The choice of N=16 static engines in Figure 6 is made on the same benchmark datasets that are later used for the headline comparisons; this is a benchmark tuning/external-validity concern, not a circularity, because the final speedups are simulation outputs rather than quantities algebraically forced by the selected N. Algorithm 2 lacks an explicit BFS frontier loop and no BFS output is validated against ground truth; this is a correctness/evaluation risk, not a circularity, since it does not involve fitting a parameter and renaming it as a prediction. Overall, the central claims are self-contained as an empirical evaluation and do not reduce to their inputs by construction.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The central claim rests on engineering assumptions rather than derivational axioms. No new physical entities are introduced; the main free parameters are architectural choices (C,T,N,M), with N effectively tuned to the benchmark set. The most fragile assumptions are the equivalence of the streaming-apply + static crossbar processing to the original graph algorithm and the generalization of pattern frequencies across datasets.

free parameters (4)
  • Crossbar size C = 4x4
    Default window size; small windows maximize all-zero subgraphs. Not derived.
  • Total graph engines T = 32
    Assumed for evaluation; no sensitivity analysis across T.
  • Static engine count N = 16 of 32
    Set to cover the 16 possible single-edge 4x4 patterns; also the optimum in Figure 6, tuned on the same datasets used for final results. This is the key tunable parameter.
  • Crossbars per engine M = 1
    Assumed for simplicity in most experiments; M>1 is mentioned only as future work.
assumptions (6)
  • standard math ReRAM crossbar performs in-situ MVM as y=Gx with O(1) complexity via Ohm's law and Kirchhoff's law
    Section II.A; the entire processing model relies on this analog linear operation.
  • domain assumption Classical graph algorithms (BFS, SSSP, PageRank) decompose into edge computation via MVM plus reduce/apply via ALU as in GraphR [10]
    Section III.D cites [10] but does not prove the mapping; correctness of the decomposed execution is never validated.
  • domain assumption Window-based non-overlapping 4x4 partitioning of the adjacency matrix with zero-subgraph removal preserves graph algorithm semantics
    Section III.B relies on GraphR-style streaming-apply execution; no formal equivalence proof is given.
  • domain assumption Pattern occurrence distributions are similar across all six datasets, so the Wiki-Vote-based observation (top 16 patterns cover 86% of subgraphs) generalizes
    Section I states 'Similar distributions were observed across all studied datasets' without showing data; this underpins the benefit of static engines.
  • domain assumption Power-law degree distribution implies single-edge subgraphs dominate in 4x4 windows
    Section IV.B invokes [29] to justify N=16; a statistical heuristic, not a theorem.
  • ad hoc to paper Circuit lifetime is captured by E/(w*C) with w equal to max writes per cell
    Section IV.D; the model ignores wear-leveling, spatial write distribution, and cell-to-cell variation, and static engines are excluded by assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Leveraging Recurrent Patterns in Graph Accelerators." pith.science (2026). https://pith.science/paper/2A7IUVR4

@misc{pith2026251201193,
  author       = {Pith},
  title        = {Pith review of: Leveraging Recurrent Patterns in Graph Accelerators},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2A7IUVR4}},
  note         = {Machine review of arXiv:2512.01193}
}
read the original abstract

Graph accelerators have emerged as a promising solution for processing large-scale sparse graphs, leveraging the in-situ compu-tation of ReRAM-based crossbars to maximize computational efficiency. However, existing designs suffer from memristor access overhead due to the large number of graph partitions. This leads to increased execution time, higher energy consumption, and re-duced circuit lifetime. This paper proposes a graph processing method that minimizes memristor write operations by identifying frequent subgraph patterns and assigning them to graph engines, referred to as static, allowing most subgraphs to be processed without a need for crossbar reconfiguration. Experimental results show speed up to 2.38x speedup and 7.23x energy savings com-pared to state-of-the-art accelerators. Furthermore, our method extends the circuit lifetime by 2x compared to state-of-the-art ReRAM graph accelerators.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 5 canonical work pages

  1. [1]

    Overall, our design is three orders of magnitude more energy efficient than GraphR and achieves 7.23× and 2.3× energy efficiency compared to SparseMEM and TARe, respectively

    Energy: Table 4 reports the energy consumption of our pro- posed design and state -of-the-art methods for executing the BFS algorithm on each dataset . Overall, our design is three orders of magnitude more energy efficient than GraphR and achieves 7.23× and 2.3× energy efficiency compared to SparseMEM and TARe, respectively. The improvement over GraphR an...

  2. [2]

    On average, our design achieves three orders of magnitude higher speedup than GraphR, and 2.38× and 1.27× over SparseMEM and TARe, respectively

    Speedup: Figure 7 compares speedup of the four designs. On average, our design achieves three orders of magnitude higher speedup than GraphR, and 2.38× and 1.27× over SparseMEM and TARe, respectively. The improvement over GraphR results from significantly reduced crossbar access, as GraphR performance is constrained by sparse subgraph mapping. Although Sp...

  3. [3]

    Finding High-Quality Content in Social Media,

    E. Agichtein, C. Castillo, D. Donato, A. Gionis, and G. Mishne, “Finding High-Quality Content in Social Media,” Feb. 2008, pp. 183 –194. doi: 10.1145/1341531.1341557

    arXiv 2008

  4. [4]

    Amazon.com recommendations: item- to-item collaborative filtering,

    G. Linden, B. Smith, and J. York, “Amazon.com recommendations: item- to-item collaborative filtering,” IEEE Internet Computing, vol. 7, no. 1, pp. 76–80, 2003, doi: 10.1109/MIC.2003.1167344

    arXiv 2003

  5. [5]

    Collaborative Fil- tering Recommender Systems,

    J. B. Schafer, D. Frankowski, J. Herlocker, and S. Sen, “Collaborative Fil- tering Recommender Systems,” in The Adaptive Web: Methods and Strat- egies of Web Personalization , P. Brusilovsky, A. Kobsa, and W. Nejdl, Eds., Berlin, Heidelberg: Springer Berlin Heidelberg, 2007, pp. 291 –324. doi: 10.1007/978-3-540-72079-9_9

    doi:10.1007/978-3-540-72079-9_9 2007

  6. [6]

    Blast2GO: a universal tool for annotation, visualization and analysis in functional genomics research,

    A. Conesa, S. Götz, J. M. García -Gómez, J. Terol, M. Talón, and M. Ro- bles, “Blast2GO: a universal tool for annotation, visualization and analysis in functional genomics research,” Bioinformatics, vol. 21, no. 18, pp. 3674–3676, Aug. 2005, doi: 10.1093/bioinformatics/bti610

    work page doi:10.1093/bioinformatics/bti610 2005

  7. [7]

    SNAP Datasets: Stanford Large Network Da- taset Collection

    J. Leskovec and A. Krevl, “SNAP Datasets: Stanford Large Network Da- taset Collection.” Jun. 2014. [Online]. Available: http://snap.stanford.edu/ data

    2014

  8. [8]

    The Network Data Repository with Inter- active Graph Analytics and Visualization,

    R. A. Rossi and N. K. Ahmed, “The Network Data Repository with Inter- active Graph Analytics and Visualization,” in AAAI, 2015. [Online]. Avail- able: https://networkrepository.com

    2015

Show all 34 references
  1. [9]

    KONECT: the Koblenz network collection,

    J. Kunegis, “KONECT: the Koblenz network collection,” in WWW Com- panion - Proceedings of the 22nd International Conference on World Wide Web, May 2013, pp. 1343–1350. doi: 10.1145/2487788.2488173

    2013

  2. [10]

    A Survey on Graph Processing Accelerators: Challenges and Opportunities,

    C.-Y. Gui et al., “A Survey on Graph Processing Accelerators: Challenges and Opportunities,” Journal of Computer Science and Technology, vol. 34, no. 2, pp. 339–371, Mar. 2019, doi: 10.1007/s11390-019-1914-z

    2019 doi

  3. [11]

    A Survey of Memory-Centric Energy Efficient Computer Architecture,

    C. Zhang, H. Sun, S. Li, Y. Wang, H. Chen, and H. Liu, “A Survey of Memory-Centric Energy Efficient Computer Architecture,” IEEE Trans- actions on Parallel and Distributed Systems , vol. 34, no. 10, pp. 2657– 2670, 2023, doi: 10.1109/TPDS.2023.3297595

    2023

  4. [12]

    GraphR: Accelerating Graph Processing Using ReRAM,

    L. Song, Y. Zhuo, X. Qian, H. Li, and Y. Chen, “GraphR: Accelerating Graph Processing Using ReRAM,” in IEEE International Symposium on High Performance Computer Architecture (HPCA) , 2018, pp. 531– 543. doi: 10.1109/HPCA.2018.00052

    2018

  5. [13]

    Performance and Accuracy Tradeoffs for Training Graph Neural Net- works on ReRAM -Based Architectures,

    A. I. Arka, B. K. Joardar, J. R. Doppa, P. P. Pande, and K. Chakrabarty, “Performance and Accuracy Tradeoffs for Training Graph Neural Net- works on ReRAM -Based Architectures,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems , vol. 29, no. 10, pp. 1743– 1756,...

    2021

  6. [14]

    Accelerating Graph Convolutional Networks Using Crossbar-based Processing -In-Memory Architectures,

    Y. Huang et al. , “Accelerating Graph Convolutional Networks Using Crossbar-based Processing -In-Memory Architectures,” in IEEE Interna- tional Symposium on High-Performance Computer Architecture (HPCA), 2022, pp. 1029–1042. doi: 10.1109/HPCA53966.2022.00079

    2022

  7. [15]

    ReGraphX: NoC -enabled 3D Heterogeneous ReRAM Architecture for Training Graph Neural Networks,

    A. I. Arka, J. R. Doppa, P. P. Pande, B. K. Joardar, and K. Chakrabarty, “ReGraphX: NoC -enabled 3D Heterogeneous ReRAM Architecture for Training Graph Neural Networks,” in Design, Automation & Test in Eu- rope Conference & Exhibition (DATE) , 2021, pp. 1667– 1672. doi: 10.239...

    2021

  8. [16]

    Spara: An Energy -Efficient ReRAM-Based Accelerator for Sparse Graph Analytics Applications,

    L. Zheng et al. , “Spara: An Energy -Efficient ReRAM-Based Accelerator for Sparse Graph Analytics Applications,” in IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2020, pp. 696–707. doi: 10.1109/IPDPS47924.2020.00077

    2020

  9. [18]

    A Task-Adaptive In-Situ ReRAM Computing for Graph Convolutional Networks,

    Y. He, B. Li, Y. Wang, C. Liu, H. Li, and X. Li, “A Task-Adaptive In-Situ ReRAM Computing for Graph Convolutional Networks,” IEEE Transac- tions on Computer-Aided Design of Integrated Circuits and Systems , vol. 43, no. 9, pp. 2635–2646, 2024, doi: 10.1109/TCAD.2024.3375251

    2024

  10. [19]

    Metal–Oxide RRAM,

    H.-S. P. Wong et al. , “Metal–Oxide RRAM,” Proceedings of the IEEE , vol. 100, no. 6, pp. 1951–1970, 2012, doi: 10.1109/JPROC.2012.2190369

    1951

  11. [20]

    19.7 A 16Gb ReRAM with 200MB/s write and 1GB/s read in 27nm technology,

    R. Fackenthal et al. , “19.7 A 16Gb ReRAM with 200MB/s write and 1GB/s read in 27nm technology,” in IEEE International Solid -State Cir- cuits Conference Digest of Technical Papers (ISSCC), 2014, pp. 338–339. doi: 10.1109/ISSCC.2014.6757460

    2014

  12. [21]

    Performance-based comparative study of exist- ing and emerging non-volatile memories: a review,

    P. Jangra and M. Duhan, “Performance-based comparative study of exist- ing and emerging non-volatile memories: a review,” Journal of Optics, vol. 52, no. 4, pp. 2395–2409, Dec. 2023, doi: 10.1007/s12596-022-01058-w

    2023 doi

  13. [22]

    PRIME: A Novel Processing -in-Memory Architecture for Neural Network Computation in ReRAM -Based Main Memory,

    P. Chi et al., “PRIME: A Novel Processing -in-Memory Architecture for Neural Network Computation in ReRAM -Based Main Memory,” in ACM/IEEE 43rd Annual International Symposium on Computer Architec- ture (ISCA), 2016, pp. 27–39. doi: 10.1109/ISCA.2016.13

    2016 doi

  14. [23]

    EMBER: Efficient Multiple- Bits-Per-Cell Embedded RRAM Macro for High-Density Digital Storage,

    A. Levy et al. , “EMBER: Efficient Multiple- Bits-Per-Cell Embedded RRAM Macro for High-Density Digital Storage,” IEEE Journal of Solid- State Circuits , vol. 59, no. 7, pp. 2081– 2092, 2024, doi: 10.1109/JSSC. 2024.3387566

  15. [24]

    Automated Testing Algorithm for the Improvement of 1T1R ReRAM Endurance,

    E. Kondratyuk et al., “Automated Testing Algorithm for the Improvement of 1T1R ReRAM Endurance,” IEEE Transactions on Electron Devices , vol. 68, no. 10, pp. 4891–4896, 2021, doi: 10.1109/TED.2021.3105089

    2021

  16. [25]

    Transparent Resistive Switching Memory Using ITO/AlN/ITO Capacitors,

    H.-D. Kim, H.- M. An, Y. Seo, and T. G. Kim, “Transparent Resistive Switching Memory Using ITO/AlN/ITO Capacitors,” IEEE Electron De- vice Letters, vol. 32, no. 8, pp. 1125–1127, 2011, doi: 10.1109/LED.2011. 2158056

    2011 doi

  17. [26]

    Overcoming the challenges of crossbar resistive memory ar- chitectures,

    C. Xu et al., “Overcoming the challenges of crossbar resistive memory ar- chitectures,” in IEEE 21st International Symposium on High Performance Computer Architecture (HPCA) , 2015, pp. 476– 488. doi: 10.1109/HPCA.2015.7056056

    2015

  18. [27]

    Dot-product engine for neuromorphic computing: Program- ming 1T1M crossbar to accelerate matrix -vector multiplication,

    M. Hu et al., “Dot-product engine for neuromorphic computing: Program- ming 1T1M crossbar to accelerate matrix -vector multiplication,” in 53rd ACM/EDAC/IEEE Design Automation Conference (DAC) , 2016, pp. 1–6. doi: 10.1145/2897937.2898010

    2016

  19. [28]

    GIM: Versatile GNN Acceleration with Reconfigurable Processing -in-Memory,

    C. Nie, G. Chen, W. Zhang, and Z. He, “GIM: Versatile GNN Acceleration with Reconfigurable Processing -in-Memory,” in IEEE 41st International Conference on Computer Design (ICCD) , 2023, pp. 499– 506. doi: 10.1109/ICCD58817.2023.00083

    2023

  20. [29]

    Janus: A Flexible Processing-in-Memory Graph Accelerator Toward Sparsity,

    X. Li et al., “Janus: A Flexible Processing-in-Memory Graph Accelerator Toward Sparsity,” IEEE Transactions on Computer-Aided Design of Inte- grated Circuits and Systems , vol. 43, no. 12, pp. 4813 –4826, 2024, doi: 10.1109/TCAD.2024.3405395

    2024

  21. [30]

    GraphIte: Accelerating Iterative Graph Algorithms on ReRAM Architectures via Approximate Computing,

    D. Choudhury, A. Kalyanaraman, and P. Pande, “GraphIte: Accelerating Iterative Graph Algorithms on ReRAM Architectures via Approximate Computing,” in Design, Automation & Test in Europe Conference & Ex- hibition (DATE), 2023. doi: 10.23919/DATE56975.2023.10137001

    2023

  22. [31]

    Random Evolution in Massive Graphs,

    W. Aiello, F. Chung, and L. Lu, “Random Evolution in Massive Graphs,” in Handbook of Massive Data Sets , J. Abello, P. M. Pardalos, and M. G. C. Resende, Eds., Boston, MA: Springer US, 2002, pp. 97 –122. doi: 10.1007/978-1-4615-0005-6_4

    2002 doi

  23. [32]

    NVSim: A Circuit- Level Per- formance, Energy, and Area Model for Emerging Nonvolatile Memory,

    X. Dong, C. Xu, Y. Xie, and N. P. Jouppi, “NVSim: A Circuit- Level Per- formance, Energy, and Area Model for Emerging Nonvolatile Memory,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 31, no. 7, pp. 994– 1007, 2012, doi: 10.1109/TCAD.2012...

    2012 doi

  24. [33]

    Cacti 6.0: A tool to model large caches,

    N. Muralimanohar, R. Balasubramonian, and N. Jouppi, “Cacti 6.0: A tool to model large caches,” HP Laboratories, Jan. 2009

    2009

  25. [34]

    A 3.1 mW 8b 1.2 GS/s Single-Channel Asynchronous SAR ADC With Alternate Comparators for Enhanced Speed in 32 nm Digital SOI CMOS,

    L. Kull et al., “A 3.1 mW 8b 1.2 GS/s Single-Channel Asynchronous SAR ADC With Alternate Comparators for Enhanced Speed in 32 nm Digital SOI CMOS,” IEEE Journal of Solid- State Circuits , vol. 48, no. 12, pp. 3049–3058, 2013, doi: 10.1109/JSSC.2013.2279571

    2013

  26. [35]

    RRAM Defect Modeling and Failure Analysis Based on March Test and a Novel Squeeze-Search Scheme,

    C.-Y. Chen et al. , “RRAM Defect Modeling and Failure Analysis Based on March Test and a Novel Squeeze-Search Scheme,” IEEE Transactions on Computers, vol. 64, no. 1, pp. 180– 190, 2015, doi: 10.1109/TC.2014. 12

    2015 doi

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.