Pith. sign in

REVIEW 4 major objections 5 minor 38 references

PIMCOMP: An End-to-End DNN Compiler for Processing-In-Memory Accelerators

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

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

Pith's one-line read PIMCOMP is an end-to-end compiler that turns an ONNX DNN into pseudo-instructions for any PIM accelerator matching its hardware template, reporting 3.3x higher throughput and up to 21.8x lower latency than three prior PIM compilers.

desk verdict A serious, well-engineered PIM compiler paper that never verifies the compiled models still work—send it to review, but require accuracy validation. read the letter →

arxiv 2411.09159 v1 pith:FLVMPQWX submitted 2024-11-14 cs.AR

Xiaotian Sun , Xinyu Wang , Wanqian Li , Yinhe Han , Xiaoming Chen This is my paper · ORCID
classification cs.AR
keywords processing-in-memoryDNNcompilercrossbararrayend-to-endcompilationdataflowschedulingweightreplicationgeneticalgorithmpseudo-instruction
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

DNN accelerators built around resistive memory promise to sidestep the memory wall, but putting a network on one of them has been a hand-crafted, per-model, per-chip chore. PIMCOMP is an end-to-end compiler designed to automate that chore: it reads a DNN in the standard ONNX format and emits pseudo-instructions that can be lowered to any accelerator matching its configurable hardware template. Its optimization stack attacks the two bottlenecks the authors identify in earlier PIM compilers — resource utilization and dataflow scheduling — by partitioning weight matrices into 'array groups' that share inputs, using a genetic algorithm to jointly choose weight replication and placement, and providing two scheduling modes (high-throughput and low-latency). In profiler simulations on three published architectures, compiled inference is reported to be 3.3x faster in throughput than the Polyhedral baseline and 21.8x, 9.8x, and 5.4x lower in latency than SongC, PUMA, and Polyhedral respectively. If those numbers hold, PIM hardware becomes something a user can program rather than a research artifact.

What carries the argument

The load-bearing object is the array group (AG): a vertical slice of an unfolded convolution weight matrix, sized so that the crossbar arrays within one core that hold it all read the same input vector. An AG is the compiler's fundamental programming unit, and it does three jobs at once — it lets one mvm pseudo-instruction drive a whole set of arrays, it decouples layers from cores (a layer's AGs can spread across cores, and one core can host AGs from many layers), and it gives the genetic algorithm a flexible but tractable unit of placement and replication. Around the AG sit two supporting mechanisms: the flexible unfolding format $(H, W, P)$ that trades computation cycles against global-memory load volume and on-chip memory, and the two dataflow schedulers that consume the AG layout and emit pseudo-instruction streams at convolution-operator granularity, using layer grouping (HT mode) or pixel-level runtime management with centralized communication (LL mode). Together these turn an ONNX model into a stream of abstract instructions that a user-supplied backend can lower to a specific accelerator.

What would settle it

Take a compiled PIMCOMP output for a standard benchmark (for example googlenet on ImageNet), simulate the pseudo-instruction stream at bit precision through the 16-bit quantization and 2-bit bit-splitting, and compare every layer's outputs and the final top-1 accuracy against the original floating-point model. If the compiled and reference networks diverge on real inputs, the reported 3.3x throughput and 21.8x latency gains describe a deployment that may not be the user's intended model.

Watch

Extended reading notes

Core claim

The paper's claim, stated in its own terms, is that automated end-to-end deployment of DNNs onto PIM accelerators is achievable through a compiler built on a high-level, configurable abstraction of the hardware rather than on any particular chip. PIMCOMP instantiates this abstraction as a multi-level template (chips, cores, PIM function units, crossbar arrays, multi-level storage) plus a small pseudo-instruction set — mvm, vec, copy, write, load, store, send, recv — that exposes each core's fundamental functionality, with user-specified execution patterns (instruction ordering, communication mechanism) adjusting the generated streams. On top of this interface, a three-stage optimizer targets the two problems the authors say previous PIM compilers mishandle: resource utilization and dataflow scheduling. Convolution weights are reshaped through a flexible unfolding format and partitioned into array groups; a genetic algorithm then determines weight replication and the placement of those groups on cores, and computational tasks are mapped to replicas in a layout-guided way that makes sliding-window inputs shareable. Two scheduling algorithms then emit pseudo-instruction streams at convolution-operator granularity, one for high throughput (layers pipelined across samples, with dependent layers grouped to cut first-batch latency) and one for low latency (output pixels forwarded to the next layer as soon as they are ready, with a pixel-level runtime manager governing memory allocation and centralized inter-core communication). The evidence is profiler-based simulation on three published architectures — an ISAAC-style chip, a PUMA-style chip, and a 16-chip edge processor — running vgg8, resnet18, resnet34, and googlenet, reporting throughput, latency, energy, resource utilization, memory traffic, and compilation time.

Load-bearing premise

The load-bearing premise is that a DNN whose weights are quantized to 16-bit fixed point and split across 2-bit analog cells still computes the original network's results correctly, and the paper reports no accuracy or functional-equivalence result to confirm it.

Editorial extensions

If this is right

  • A user can deploy an ONNX-exported DNN to a PIM accelerator without rewriting the model: the frontend reads it, the optimizer makes the mapping and scheduling decisions, and the backend lowers the result to hardware primitives.
  • A single compiler covers both throughput-oriented cloud workloads and latency-sensitive edge workloads, because the two scheduling modes differ only in inter-layer pipeline granularity.
  • Weight replication and weight layout are decided jointly rather than independently, so added parallelism does not come with mismatched storage requirements; the reported average resource utilization is 38.8% higher than the Polyhedral baseline.
  • The system-level optimizations are separable and individually visible: layer grouping cuts first-batch latency by up to 6.4x, flexible unfolding cuts global-memory traffic by up to 3.8x, and the pixel-level runtime manager cuts local-memory demand by up to 83.7x while improving latency by up to 15.2x.
  • Because the same frontend and optimizer drive three different instantiated architectures, the portability claim is checked, not assumed.

Reading between the lines

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

  • The paper's own evidence stops at throughput, latency, energy, and resource use; it never reports inference accuracy after the backend's 16-bit fixed-point quantization and 2-bit bit-splitting. The most direct extension — and the test that would confirm the compiled streams compute the intended networks — is a bit-accurate functional simulation comparing each compiled model's outputs to the unquan
  • The pseudo-instruction set functions like a portable intermediate representation for PIM. If the backend-lowering interface catches on, model owners could ship compiled streams once and chip vendors could provide only the lowering library — the 'PIM ecosystem' the paper mentions but does not develop.
  • Compilation time is dominated by the genetic-algorithm search (roughly 7 to 36 minutes per model on Arch-A) and scales with architecture size; since the paper treats this as a one-time cost, replacing the profiler-guided fitness with a fast analytical or learned cost model is a natural scaling extension for larger accelerators.
  • Because PIMCOMP is open-sourced, all of the above is testable without reimplementation: someone with the repository can reproduce the profiler numbers and add the missing accuracy check.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 presents PIMCOMP, an end-to-end DNN compiler for crossbar-based processing-in-memory (PIM) accelerators. PIMCOMP introduces an abstract configurable accelerator template with a pseudo-instruction interface, a frontend that consumes ONNX models, a multi-stage optimizer (layer partitioning with array groups and flexible unfolding, GA-based weight-layout and replication optimization, and adaptive computation-storage mapping), and two dataflow scheduling modes (high-throughput and low-latency). A backend performs 16-bit fixed-point weight quantization, bit-splitting onto 2-bit crossbar cells, and translation to hardware-specific primitives. The evaluation uses an in-house profiler to report throughput, latency, energy, and resource utilization on three architectures, comparing PIMCOMP against reimplementations of SongC, PUMA, and Polyhedral.

Significance. If the central claims are substantiated, PIMCOMP would be a notable advance in automating DNN deployment on PIM hardware: it addresses two system-level concerns, resource utilization and dataflow scheduling, through a coherent compilation pipeline; it offers a flexible hardware abstraction; and it is open-sourced, which is valuable for reproducible research. The proposed array-group granularity, weight-layout guided mapping, and pixel-level runtime management are well-motivated and the experiments are extensive. However, the paper does not report any inference accuracy or functional-equivalence checks for the compiled models after quantization and bit-splitting, and the performance evaluation relies entirely on a profiler that also serves as the GA fitness function. These omissions leave the end-to-end correctness claim and the credibility of the quantitative speedups unverified.

major comments (4)
  1. [Section VIII-A and VIII-B] The paper claims in Section II that an end-to-end DNN compiler should compile a model into 'logically correct instructions,' yet Section VIII reports only throughput, latency, energy, and resource utilization. Nowhere is the accuracy of the compiled models measured: after the backend quantizes weights to 16-bit fixed-point and bit-splits them onto 2-bit crossbar cells (Section IV-C), no top-1/top-5 accuracy, layer-output equivalence, or any functional-correctness metric is given. Without such a check, a reader cannot know whether the compiled pseudo-instruction streams deploy the intended network or some numerically corrupted approximation. This is the load-bearing gap for the 'end-to-end deployment' claim and must be filled with accuracy measurements (or per-layer output comparison) on all four benchmarks across the three architectures.
  2. [Section VI-A and VIII-A] The profiler is used both as the GA fitness function during layout-computation mapping (Section VI-A) and as the sole evaluation tool for the final reported performance (Section VIII-A). PIMCOMP is thus optimizing for the same yardstick on which it is judged, so the improvements over the baselines could reflect the profiler's modeling assumptions rather than physical-system advantages. The paper should validate the profiler against an independent cycle-accurate simulator or real hardware for at least one representative configuration, and ideally report sensitivity to profiler parameters and confidence intervals across multiple GA runs.
  3. [Section VIII-A, Table V] The evaluation changes Arch-C from the originally published design [33] by expanding the chip count from 4 to 16 'to ensure sufficient PIM resources to accommodate complete DNN models.' This is a non-trivial modification of the hardware under evaluation; it means the experiments do not use the actual Arch-C architecture as reported in the literature, and any comparison with published Arch-C results is not on equal footing. The authors should justify that this modification stays within the abstraction's intended configurability, describe the resulting accelerator (e.g., total storage, connectivity), and discuss whether the modified configuration is realistic or representative.
  4. [Section VIII-A] The three baselines (SongC, PUMA, Polyhedral) are reimplemented by the authors 'faithfully within our compiler,' and all performance numbers come from the same in-house profiler. To guard against unconscious bias and to enable reproducibility, the baselines should be run using the original implementations when available, or the reimplementations should be released as part of the open-source artifact. In addition, the GA is stochastic (Section VI-A), but no variance, confidence intervals, or number of GA runs are reported for the performance results in Figures 10-17 or for compilation time in Table VI.
minor comments (5)
  1. [Section III and Table III] There are several typos and inconsistencies: 'GloalMem' should be 'GlobalMem', 'out-of-oder' in Fig. 2 should be 'out-of-order', and the figure text uses 'LocalMem' while the body usually says 'local memory'. Also, some numbered items in the text are formatted as 'I.' and 'II.' rather than a standard list style.
  2. [Section V-B, Table IV] The notation (H, W, P) is clear in the caption, but the table would benefit from a sentence defining the columns 'Computation cycle', 'Load volume', and 'Additional memory' in units of input/output feature maps (Fin, Fout, K, I, O). Currently the reader must infer what S, M, L mean.
  3. [Section VI-A] The chromosome encoding uses gene value = layer_index × 10000 + AG_num, which implicitly limits the number of AGs per layer per core to 9999. This constraint is not justified and could be a hidden limitation for very large layers.
  4. [Section VIII] Figures 10-17 show bar charts without error bars or statistical significance indicators. Given that the GA is stochastic, the authors should report at least the mean and standard deviation over several optimization runs, or state that a fixed seed was used and a single run is representative.
  5. [Throughout] Several paragraphs contain incomplete or run-on sentences (e.g., in Section III-A, 'The local memory represents an abstraction of all storage units within a core, facilitating data exchange with both PIMFUs and VFUs while also storing data transmitted between cores.') Minor editing for grammar and punctuation would improve readability.

Circularity Check

1 steps flagged · score 6.0 of 10

Performance gains are reported by the same profiler that serves as the GA fitness function, so the claimed improvements are the optimized objective rather than an independent prediction.

  1. fitted input called prediction [Section VI-A (GA-based Weight Layout Optimization) and Section VIII-A (Experimental Setup)]
    "for each mapping represented by a chromosome, we perform the dataflow scheduling process mentioned later to generate a pseudo-instruction stream. This stream is not the final complete sequence; rather, it is a simplified version used for rapid evaluation by the profiler to obtain the performance considering computation, memory access, and communication as the fitness function. ... We conduct simulation through the profiler described in Section IV, which provides performance metrics such as inference latency, throughput, and energy consumption."

    The GA fitness function is the profiler's performance estimate, and the evaluation section uses that same profiler to produce every reported throughput, latency, and energy number. The compiler's weight-layout and scheduling decisions are therefore fitted to the profiler objective, and the reported improvements are the value of that same objective after optimization, not an independent measurement. Section IV-B explicitly describes the latter two stages as forming a 'closed-loop iterative optimization' under profiler feedback, and Section VIII-A then treats the profiler's output as the experimental result.

full rationale

Most of PIMCOMP is a compiler-construction artifact and does not contain circular derivations: the unfolding algebra (HW P = IOK^2), the array-group arithmetic, and the layer-group latency calculation are straightforward, and no result depends on an imported uniqueness theorem or on a load-bearing self-citation chain. Reference [12] is acknowledged as the prior blueprint, but the current paper's algorithms and experiments are implemented and evaluated on their own. The one substantial circularity is evaluative: the profiler is used both as the GA fitness function (Section VI-A) and as the source of all reported performance metrics (Section VIII-A), so the claimed speedups are the optimized objective rather than an independent check. The paper never validates the profiler against real hardware or an independent simulator, and it also omits any accuracy or functional-equivalence measurement after 16-bit weight quantization and 2-bit bit-splitting; that omission is a correctness risk but not itself a circularity, because the absence of a test does not make the derivation definitionally self-referential. Given the profiler feedback loop, a score of 6 is appropriate: the performance conclusions partially reduce to the optimization setup, while the compiler's program transformations themselves remain nontrivial and are not equation-identical to the reported metrics.

Assumptions & free parameters 5 free parameters · 5 assumptions · 1 invented entities

The central claims rest on two unvalidated pillars: the profiler is both optimizer and evaluator, and no functional accuracy check is reported. Free parameters are mostly GA and scheduling hyperparameters; the main invented abstraction is the array group. Hardware assumptions come from prior published accelerators.

free parameters (5)
  • GA population size = 200
    Section VIII-D states the population size is 200; no sensitivity analysis is provided, so search quality depends on this hand-picked value.
  • GA iteration limit = up to 1000
    Table VI reports compilation times using up to 1000 iterations; no convergence criterion or ablation is given.
  • Communication trigger threshold = unspecified
    Algorithm 2 lines 13-14 trigger transmission when the request count reaches 'a certain threshold'; the threshold is never defined, making latency results depend on an unstated parameter.
  • Arch-C chip count = 16 chips (expanded from 4)
    Section VIII-A expands the published 4-chip design to 16 chips so full models fit, changing the hardware being evaluated.
  • Weight quantization precision = 16-bit fixed point on 2-bit cells
    Section VIII-A assumes 16-bit weights on 2-bit crossbars via bit splitting; no accuracy or precision sensitivity validation is reported.
assumptions (5)
  • domain assumption The in-house profiler's timing, energy, and conflict models are accurate enough to rank mappings and compare compilers.
    Used in Section VI-A as the GA fitness function and in Section VIII-A as the sole measurement instrument; no validation against real hardware or an independent simulator is provided.
  • domain assumption The abstract architecture template faithfully instantiates real PIM accelerators, so optimizations transfer to actual hardware.
    Section III claims compatibility based on the template; only three simulated instantiations are tested.
  • domain assumption The compiled programs preserve the inference accuracy of the original DNN after quantization, bit splitting, and scheduling.
    No accuracy or functional verification is reported in Section VIII; compiler correctness is assumed.
  • ad hoc to paper GA chromosomes and mutations cover the space of weight replication and layout well enough to find near-optimal mappings.
    Section VI-A introduces the encoding and mutations; no formal guarantees or comparison with exhaustive or random search are provided.
  • domain assumption Convolution operators without structural or data conflicts can execute in parallel on cores without hidden resource conflicts.
    This is the basis for operator-level scheduling in Section VII; with arbitrary management granularity, conflicts could differ.
invented entities (1)
  • Array group (AG)
    purpose: A set of crossbar arrays sharing an input, defined as the fundamental unit for weight layout, mapping, and scheduling (Section V-A).
    This is a new software/programming abstraction introduced by the paper; its effectiveness is demonstrated only inside PIMCOMP's own profiler and not by an external benchmark.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PIMCOMP: An End-to-End DNN Compiler for Processing-In-Memory Accelerators." pith.science (2026). https://pith.science/paper/FLVMPQWX

@misc{pith2026241109159,
  author       = {Pith},
  title        = {Pith review of: PIMCOMP: An End-to-End DNN Compiler for Processing-In-Memory Accelerators},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FLVMPQWX}},
  note         = {Machine review of arXiv:2411.09159}
}
read the original abstract

Various processing-in-memory (PIM) accelerators based on various devices, micro-architectures, and interfaces have been proposed to accelerate deep neural networks (DNNs). How to deploy DNNs onto PIM-based accelerators is the key to explore PIM's high performance and energy efficiency. The scale of DNN models, the diversity of PIM accelerators, and the complexity of deployment are far beyond the human deployment capability. Hence, an automatic deployment methodology is indispensable. In this work, we propose PIMCOMP, an end-to-end DNN compiler tailored for PIM accelerators, achieving efficient deployment of DNN models on PIM hardware. PIMCOMP can adapt to various PIM architectures by using an abstract configurable PIM accelerator template with a set of pseudo-instructions, which is a high-level abstraction of the hardware's fundamental functionalities. Through a generic multi-level optimization framework, PIMCOMP realizes an end-to-end conversion from a high-level DNN description to pseudo-instructions, which can be further converted to specific hardware intrinsics/primitives. The compilation addresses two critical issues in PIM-accelerated inference from a system perspective: resource utilization and dataflow scheduling. PIMCOMP adopts a flexible unfolding format to reshape and partition convolutional layers, adopts a weight-layout guided computation-storage-mapping approach to enhance resource utilization, and balances the system's computation, memory access, and communication characteristics. For dataflow scheduling, we design two scheduling algorithms with different inter-layer pipeline granularities to support varying application scenarios while ensuring high computational parallelism. Experiments demonstrate that PIMCOMP improves throughput, latency, and energy efficiency across various architectures. PIMCOMP is open-sourced at \url{https://github.com/sunxt99/PIMCOMP-NN}.

Figures

Figures reproduced from arXiv: 2411.09159 by the authors.

Figure 1
Figure 1. Architecture template. architecture. Based on this, we propose configurable execution patterns to specify the execution logic of the abstract hardware, facilitating the compilation adapting to the actual hardware execution patterns. A. Architecture Template The architecture template is a representative multi-level con￾figurable and scalable architecture derived from previous PIM accelerators [5], [22], [22], [26] [… view at source ↗
Figure 2
Figure 2. Example of adjustment based on instruction execution [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 4
Figure 4. Overview of PIMCOMP. A. Frontend The frontend parses the DNN model and converts it into IRs, eliminating the need for users to rewrite the model. PIMCOMP supports DNN models described in the ONNX format, which can be easily obtained from various frameworks such as PyTorch and TensorFlow, thus enabling PIMCOMP’s compatibility with multiple deep learning frameworks. To enable efficient deployment, the frontend adopts … view at source ↗
Figures from the paper (9 more)
Figure 5
Figure 5. Figure 5: Pipeline schematic under HT and LL modes. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Unfolding strategy for convolutional kernels and par [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Example of using GA to optimize weight layout consid [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Different computational tasks allocation approaches. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: Pixel-level runtime management strategy. [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 12
Figure 12. Figure 12: Latency and resource utilization of LL scenario. [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]
Figure 13
Figure 13. Figure 13: Energy savings of LL scenario. optimization effect on Arch-C is somewhat less pronounced than on Arch-A and Arch-B. 2) Low Latency Mode [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 15
Figure 15. Figure 15: Global memory ac￾cess volume of HT scenario. vgg8 resnet18 resnet34 googlenetvgg8 resnet18 resnet34 googlenetvgg8 resnet18 resnet34 googlenet 0.0 2.5 5.0 7.5 10.0 12.5 15.0 Normalized Latency Improvements Arch-A Arch-B Arch-C 3.9x 15.2x 8.1x 10.8x 2.0x 12.8x 8.7x 12.1…
Figure 16
Figure 16. Figure 16: Inference latency of LL scenario. vgg8 resnet18 resnet34 googlenetvgg8 resnet18 resnet34 googlenetvgg8 resnet18 resnet34 googlenet 0 5 10 15 20 Normalized Local Memory Savings Arch-A Arch-B Arch-C 5.8x 9.6x 6.1x 13.9x 5.1x 13.3x 11.2x 13.5x 19.2x 50 75 35.1x 41.6x 83.…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 35 canonical work pages

  1. [33]

    A nonvolatile al-edge processor with 4mb slc-mlc hybrid-mode reram compute-in-memory macro and 51.4-251tops/w,

    W.-H. Huang, T.-H. Wen, J.-M. Hung, W.-S. Khwa, Y .-C. Lo, C.-J. Jhang, H.-H. Hsu, Y .-H. Chin, Y .-C. Chen, C.-C. Lo, R.-S. Liu, K.- T. Tang, C.-C. Hsieh, Y .-D. Chih, T.-Y . Chang, and M.-F. Chang, “A nonvolatile al-edge processor with 4mb slc-mlc hybrid-mode reram compute-in-memory macro and 51.4-251tops/w,” in IEEE Int. Solid- State Circuits Conf. , p...

    work page 2023

  2. [1]

    Eie: efficient inference engine on compressed deep neural network,

    S. Han, X. Liu, H. Mao, J. Pu, A. Pedram, M. A. Horowitz, and W. J. Dally, “Eie: efficient inference engine on compressed deep neural network,” in Proc. ACM/IEEE Annu. Int. Symp. Comput. Architect. , p. 243–254, 2016. TABLE VI: Compilation time (second). vgg8 resnet18 resnet34 googlenet HT LL HT LL HT LL HT LL P1 0.0 0.1 0.1 0.1 0.6 0.6 0.6 0.6 M2 1034.4 ...

    work page 2016

  3. [2]

    Dadiannao: A machine-learning supercomputer,

    Y . Chen, T. Luo, S. Liu, S. Zhang, L. He, J. Wang, L. Li, T. Chen, Z. Xu, N. Sun, and O. Temam, “Dadiannao: A machine-learning supercomputer,” in Annu. IEEE/ACM Int. Symp. Microarchit. , pp. 609– 622, 2014

    work page 2014

  4. [3]

    Scaling the

    S.-L. Lu, T. Karnik, G. Srinivasa, K.-Y . Chao, D. Carmean, and J. Held, “Scaling the ”memory wall”,” in Proc. IEEE/ACM Int. Conf. Comput. Aided Design, p. 271–272, 2012

    work page 2012

  5. [4]

    First demonstration of oxrram integration on 14nm finfet platform and scaling potential analysis towards sub-10nm node,

    X. Xu, J. Yu, T. Gong, J. Yang, J. Yin, D. Nian Dong, Q. Luo, J. Liu, Z. Yu, Q. Liu, H. Lv, and M. Liu, “First demonstration of oxrram integration on 14nm finfet platform and scaling potential analysis towards sub-10nm node,” in Annu. IEEE Int. Electron Devices Meeting , pp. 24.3.1–24.3.4, 2020

    work page 2020

  6. [5]

    Isaac: a convolutional neural network accelerator with in-situ analog arithmetic in crossbars,

    A. Shafiee, A. Nag, N. Muralimanohar, R. Balasubramonian, J. P. Stra- chan, M. Hu, R. S. Williams, and V . Srikumar, “Isaac: a convolutional neural network accelerator with in-situ analog arithmetic in crossbars,” in Proc. ACM/IEEE Annu. Int. Symp. Comput. Architect., p. 14–26, 2016

    work page 2016

  7. [6]

    Prime: a novel processing-in-memory architecture for neural network computation in reram-based main memory,

    P. Chi, S. Li, C. Xu, T. Zhang, J. Zhao, Y . Liu, Y . Wang, and Y . Xie, “Prime: a novel processing-in-memory architecture for neural network computation in reram-based main memory,” in Proc. ACM/IEEE Annu. Int. Symp. Comput. Architect. , p. 27–39, 2016

    work page 2016

  8. [7]

    Pipelayer: A pipelined reram- based accelerator for deep learning,

    L. Song, X. Qian, H. Li, and Y . Chen, “Pipelayer: A pipelined reram- based accelerator for deep learning,” in Proc. IEEE Int. Symp. High Perform. Comput. Archit., pp. 541–552, 2017

    work page 2017

Show all 38 references
  1. [8]

    Efficient fefet crossbar accelerator for binary neural networks,

    T. Soliman, R. Olivo, T. Kirchner, C. D. l. Parra, M. Lederer, T. K ¨ampfe, A. Guntoro, and N. Wehn, “Efficient fefet crossbar accelerator for binary neural networks,” in IEEE Int. Conf. Appl. Sys. Archit. Process. (ASAP) , pp. 109–112, 2020

    2020

  2. [9]

    A crossbar array of magnetoresistive memory devices for in-memory computing,

    S. Jung, H. Lee, S. Myung, H. Kim, S. K. Yoon, S.-W. Kwon, Y . Ju, M. Kim, W. Yi, S. Han, B. Kwon, B. Seo, K. Lee, G.-H. Koh, K. Lee, Y . Song, C. Choi, D. Ham, and S. J. Kim, “A crossbar array of magnetoresistive memory devices for in-memory computing,” Nature, vol. 601, pp. ...

    2022

  3. [10]

    Enabling high-performance dnn inference accelerators using non-volatile analog memory,

    A. Chen, S. Ambrogio, P. Narayanan, H. Tsai, C. Mackin, K. Spoon, A. Friz, A. Fasoli, and G. W. Burr, “Enabling high-performance dnn inference accelerators using non-volatile analog memory,” in IEEE Electron Devices Technol. Manuf. Conf. (EDTM) , pp. 1–4, 2020

    2020

  4. [11]

    Memory devices and applications for in-memory computing,

    A. Sebastian, M. Le Gallo, R. Khaddam-Aljameh, and E. Eleftheriou, “Memory devices and applications for in-memory computing,” Nature Nanotechnology, vol. 15, pp. 529–544, Jul 2020

    2020

  5. [12]

    Pimcomp: A universal compilation framework for crossbar-based pim dnn accelera- tors,

    X. Sun, X. Wang, W. Li, L. Wang, Y . Han, and X. Chen, “Pimcomp: A universal compilation framework for crossbar-based pim dnn accelera- tors,” in Proc. Design Autom. Conf. , pp. 1–6, 2023

    2023

  6. [13]

    TVM: An automated End-to-End optimizing compiler for deep learning,

    T. Chen, T. Moreau, Z. Jiang, L. Zheng, E. Yan, H. Shen, M. Cowan, L. Wang, Y . Hu, L. Ceze, C. Guestrin, and A. Krishnamurthy, “TVM: An automated End-to-End optimizing compiler for deep learning,” in USENIX Symp. Oper. Sys. Design Impl. , pp. 578–594, 2018

    2018

  7. [14]

    End-to-end programmable computing systems,

    Y . Xiao, G. Ma, N. K. Ahmed, M. Capot ˘a, T. L. Willke, S. Nazarian, and P. Bogdan, “End-to-end programmable computing systems,” Com- munications Engineering, vol. 2, p. 84, Nov 2023

    2023

  8. [15]

    Plasticity-on-chip design: Ex- ploiting self-similarity for data communications,

    Y . Xiao, S. Nazarian, and P. Bogdan, “Plasticity-on-chip design: Ex- ploiting self-similarity for data communications,” IEEE Transactions on Computers, vol. 70, no. 6, pp. 950–962, 2021

    2021

  9. [16]

    Polyhedral-based compilation framework for in-memory neural network accelerators,

    J. Han, X. Fei, Z. Li, and Y . Zhang, “Polyhedral-based compilation framework for in-memory neural network accelerators,” J. Emerg. Tech- nol. Comput. Syst. , vol. 18, sep 2021

    2021

  10. [17]

    Hardware- software co-design for an analog-digital accelerator for machine learn- ing,

    J. Ambrosi, A. Ankit, R. Antunes, S. R. Chalamalasetti, S. Chatterjee, I. E. Hajj, G. Fachini, P. Faraboschi, M. Foltin, S. Huang, W.-M. Hwu, G. Knuppe, S. V . Lakshminarasimha, D. Milojicic, M. Parthasarathy, F. Ribeiro, L. Rosa, K. Roy, P. Silveira, and J. P. Strachan, “Hard...

    2018

  11. [18]

    Songc: A compiler for hybrid near-memory and in-memory many-core architecture,

    J. Lin, H. Qu, S. Ma, X. Ji, H. Li, X. Li, C. Song, and W. Zhang, “Songc: A compiler for hybrid near-memory and in-memory many-core architecture,” IEEE Trans. Comput. , pp. 1–14, 2023. 14

    2023

  12. [19]

    Tc-cim: Empowering tensor compre- hensions for computing-in-memory,

    A. Drebes, L. Chelini, O. Zinenko, A. Cohen, H. Corporaal, T. Grosser, K. Vadivel, and N. Vasilache, “Tc-cim: Empowering tensor compre- hensions for computing-in-memory,” in Int. Workshop on Poly. Compil. Tech., 2020

    2020

  13. [20]

    Tdo-cim: Transparent detection and offloading for computation in-memory,

    K. Vadivel, L. Chelini, A. BanaGozar, G. Singh, S. Corda, R. Jordans, and H. Corporaal, “Tdo-cim: Transparent detection and offloading for computation in-memory,” in Proc. Design Autom. Test Europe Conf. Exhibit., pp. 1602–1605, 2020

    2020

  14. [21]

    Occ: An automated end-to- end machine learning optimizing compiler for computing-in-memory,

    A. Siemieniuk, L. Chelini, A. A. Khan, J. Castrillon, A. Drebes, H. Corporaal, T. Grosser, and M. Kong, “Occ: An automated end-to- end machine learning optimizing compiler for computing-in-memory,” IEEE Trans. Comput. Aided Design Integr. Circuits Syst., vol. 41, no. 6, pp. 16...

    2022

  15. [22]

    Puma: A programmable ultra-efficient memristor-based accelerator for machine learning inference,

    A. Ankit, I. E. Hajj, S. R. Chalamalasetti, G. Ndu, M. Foltin, R. S. Williams, P. Faraboschi, W.-m. W. Hwu, J. P. Strachan, K. Roy, and D. S. Milojicic, “Puma: A programmable ultra-efficient memristor-based accelerator for machine learning inference,” in Proc. Int. Conf. Archi...

    2019

  16. [23]

    Cinm (cinnamon): A compilation infrastructure for hetero- geneous compute in-memory and compute near-memory paradigms,

    A. A. Khan, H. Farzaneh, K. F. Friebel, L. Chelini, and J. Cas- trillon, “Cinm (cinnamon): A compilation infrastructure for hetero- geneous compute in-memory and compute near-memory paradigms,” arXiv:2301.07486, 2022

    2022 arXiv

  17. [24]

    Mathematical framework for optimizing crossbar allocation for reram-based cnn accelerators,

    W. Li, Y . Han, and X. Chen, “Mathematical framework for optimizing crossbar allocation for reram-based cnn accelerators,” ACM Trans. Des. Autom. Electron. Syst. , vol. 29, dec 2023

    2023

  18. [25]

    Introduction to hardware abstraction layers for soc,

    S. Yoo and A. Jerraya, “Introduction to hardware abstraction layers for soc,” in Proc. Design Autom. Test Europe Conf. Exhibit. , pp. 336–337, 2003

    2003

  19. [26]

    Atomlayer: a universal reram-based cnn accelerator with atomic layer computation,

    X. Qiao, X. Cao, H. Yang, L. Song, and H. Li, “Atomlayer: a universal reram-based cnn accelerator with atomic layer computation,” in Proc. Design Autom. Conf. , 2018

    2018

  20. [27]

    Mnsim 2.0: A behavior-level modeling tool for processing-in-memory architectures,

    Z. Zhu, H. Sun, T. Xie, Y . Zhu, G. Dai, L. Xia, D. Niu, X. Chen, X. S. Hu, Y . Cao, Y . Xie, H. Yang, and Y . Wang, “Mnsim 2.0: A behavior-level modeling tool for processing-in-memory architectures,” IEEE Trans. Comput. Aided Design Integr. Circuits Syst., vol. 42, no. 11, pp...

    2023

  21. [28]

    Cmq: Crossbar- aware neural network mixed-precision quantization via differentiable architecture search,

    J. Peng, H. Liu, Z. Zhao, Z. Li, S. Liu, and Q. Li, “Cmq: Crossbar- aware neural network mixed-precision quantization via differentiable architecture search,” IEEE Trans. Comput. Aided Design Integr. Circuits Syst., vol. 41, no. 11, pp. 4124–4133, 2022

    2022

  22. [29]

    Mixed size crossbar based rram cnn accelerator with overlapped mapping method,

    Z. Zhu, J. Lin, M. Cheng, L. Xia, H. Sun, X. Chen, Y . Wang, and H. Yang, “Mixed size crossbar based rram cnn accelerator with overlapped mapping method,” in Proc. IEEE/ACM Int. Conf. Comput.- Aided Design, p. 1–8, 2018

    2018

  23. [30]

    Optimizing weight mapping and data flow for convolutional neural networks on rram based processing-in-memory architecture,

    X. Peng, R. Liu, and S. Yu, “Optimizing weight mapping and data flow for convolutional neural networks on rram based processing-in-memory architecture,” in Proc. IEEE Int. Symp. Circuits Syst. , pp. 1–5, 2019

    2019

  24. [31]

    A convolution neural network accelerator design with weight mapping and pipeline optimization,

    L. Han, P. Huang, Z. Zhou, Y . Chen, X. Liu, and J. Kang, “A convolution neural network accelerator design with weight mapping and pipeline optimization,” in Proc. Design Autom. Conf. , pp. 1–6, 2023

    2023

  25. [32]

    Benchmarking dnn mapping methods for the in-memory computing accelerators,

    Y . Wang and X. Fong, “Benchmarking dnn mapping methods for the in-memory computing accelerators,” IEEE J. Emerg. Sel. Topics Circuits Sys., vol. 13, no. 4, pp. 1040–1051, 2023

    2023

  26. [34]

    Cacti 7: New tools for interconnect exploration in innovative off-chip memories,

    R. Balasubramonian, A. B. Kahng, N. Muralimanohar, A. Shafiee, and V . Srinivas, “Cacti 7: New tools for interconnect exploration in innovative off-chip memories,”ACM Trans. Archit. Code Optim., vol. 14, jun 2017

    2017

  27. [35]

    Orion3.0: A comprehensive noc router estimation tool,

    A. B. Kahng, B. Lin, and S. Nath, “Orion3.0: A comprehensive noc router estimation tool,” IEEE Embedded Systems Letters , vol. 7, no. 2, pp. 41–45, 2015

    2015

  28. [36]

    Very deep convolutional networks for large-scale image recognition,

    K. Simonyan and A. Zisserman, “Very deep convolutional networks for large-scale image recognition,” CoRR, vol. abs/1409.1556, 2014

    2014 arXiv

  29. [37]

    Deep residual learning for image recognition,

    K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” in Proc. IEEE Conf. Comput. Vision Pattern Recog. (CVPR), June 2016

    2016

  30. [38]

    Going deeper with convolutions,

    C. Szegedy, W. Liu, Y . Jia, P. Sermanet, S. E. Reed, D. Anguelov, D. Erhan, V . Vanhoucke, and A. Rabinovich, “Going deeper with convolutions,” in Proc. IEEE Conf. Comput. Vision Pattern Recog. (CVPR), pp. 1–9, 2014. Xiaotian Sun received the B.S. degree in elec- tronic engin...

    2014

Pith tools

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