CIM-MLC: Multi-Level Compilation for CIM
- CIM-MLC is a universal multi-level compilation framework for CIM architectures that defines a three-tier abstraction to enable hierarchical scheduling of DNN operators.
- It overcomes diversity in memory devices, architecture hierarchies, and programming granularities through a staged optimization pipeline (CG-, MVM-, and VVM-grained).
- The framework demonstrates significant performance gains, achieving up to 3.7× speedup and 75% peak power reduction compared to prior CIM compilation approaches.
to=arxiv_search.search 日日啪 彩经彩票 json {"query":"(Qu et al., 2024) CIM-MLC multi-level compilation stack computing-in-memory accelerators", "max_results": 5} to=arxiv_search.search 天天爱彩票网站 json {"query":"computing-in-memory compiler multi-level compilation stack CIM arXiv 2024 (Qu et al., 2024)", "max_results": 10} to=arxiv_search.search 玩大发快三 json {"query":"CIM-MLC: A Multi-level Compilation Stack for Computing-In-Memory Accelerators", "max_results": 3} CIM-MLC denotes a universal multi-level compilation framework for general computing-in-memory (CIM) architectures. It was proposed to address a recurrent systems problem in CIM research: accelerators differ substantially in memory device, architecture hierarchy, and programming interface / granularity, so compilers built for one design often generalize poorly to others. CIM-MLC responds by defining a general hardware abstraction for CIM architectures and computing modes and by compiling deep neural networks through a multi-level scheduling pipeline that progressively refines mapping and scheduling from coarse to fine granularity. Its stated objective is not only portability across diverse CIM hardware, but also exploration of mapping and scheduling strategies across multiple architectural tiers to improve scheduling and instruction generation results (Qu et al., 2024).
1. Problem formulation and architectural motivation
CIM-MLC is situated in a compiler landscape where many existing approaches are either bound to a fixed CIM architecture or optimize only a single abstraction level, most often matrix-vector multiplication (MVM) granularity. The motivating observation is that CIM accelerators vary along several axes: SRAM, ReRAM, FLASH, and other memory devices; different chip/core/crossbar organizations; and interfaces that may expose coarse DNN operators, MVMs, or row-level read/write primitives. Under these conditions, a compiler that ignores hierarchy or assumes one fixed execution granularity misses optimization opportunities and may not support the intended hardware at all (Qu et al., 2024).
The framework therefore treats compilation for CIM as a hierarchical optimization problem. Rather than flattening the architecture into a single compute primitive, it models CIM at multiple tiers and aligns compiler decisions with the granularity that the hardware actually exposes. This design directly addresses several shortcomings identified in prior compilation work: insufficient modeling of architecture hierarchy, limited support for scheduling below the graph level, and lack of flexibility for architectures with different exposed programming interfaces. A plausible implication is that CIM-MLC treats portability and performance as coupled compiler concerns rather than separate layers of the toolchain.
2. Three-tier hardware abstraction and compute modes
The central abstraction in CIM-MLC is a three-tier architecture model consisting of the chip tier, core tier, and crossbar tier. This hierarchy is paired with three compute modes: CM (Core Mode), XBM (Crossbar Mode), and WLM (Wordline Mode). Together they define the compilation space over which the framework schedules operators and generates instructions (Qu et al., 2024).
| Tier | Mode | Representative parameters |
|---|---|---|
| Chip tier | CM | core_number, core_noc, core_noc_cost, L0 size, L0 BW, ALU |
| Core tier | XBM | xb_number, xb_noc, xb_noc_cost, L1 size, L1 BW, ALU |
| Crossbar tier | WLM | xb_size, parallel row, Type, Precision, DAC, ADC |
At the chip tier, CIM-MLC models multiple cores connected by a NoC, shared on-chip memory, and ALUs for non-CIM computation. CM is the coarsest compute mode: one or more cores execute one DNN operator, which is suitable for architectures that expose coarse operator-level execution. At the core tier, each core contains multiple crossbars, local buffers, digital units, and an intra-core interconnect. XBM captures execution at crossbar-level MVM granularity. At the crossbar tier, the compiler models the array itself, including rows/wordlines, independent row activation, and converter precision. WLM is the finest mode and supports row-wise reads/writes and row-level scheduling decisions (Qu et al., 2024).
This abstraction is broad by design. It can vary device type, crossbar size, crossbar count per core, programming interface, and computing granularity. That breadth is the reason CIM-MLC is described as supporting a wide range of CIM accelerators rather than a single device family.
3. Meta-operators, instruction model, and staged compilation
CIM-MLC compiles from an ONNX DNN graph and progressively refines execution through three stages: CG-grained optimization on CM, MVM-grained optimization on XBM, and VVM-grained optimization on WLM. It does not rely exclusively on conventional ML compiler primitives; instead, it introduces meta-operator sets for each compute mode: MOP_CM, MOP_XBM, and MOP_WLM. It also uses DCOM for digital computation operators and DMOV for data movement operators. The instruction vocabulary includes CIM.read_core, CIM.read_crossbar, CIM.write_crossbar, CIM.read_row, and CIM.write_row (Qu et al., 2024).
In the CG-grained stage, the compiler operates on the computational graph and optimizes operator mapping onto cores using operator duplication and pipeline scheduling under core_number constraints. It estimates latency and resource use per node, applies dynamic programming to search duplication numbers, and updates node attributes in the ONNX graph. If the entire model cannot fit, it splits the graph into maximal subgraphs and iteratively trims nodes until adding more no longer improves latency.
In the MVM-grained stage, the key scheduling unit is the Virtual Crossbar (VXB) rather than the physical crossbar. VXB is defined through dimension binding between matrix dimensions and crossbar dimensions. This stage refines duplication, pipelines crossbar activations, and reduces peak power by activating a crossbar as soon as it receives its input rather than waiting for all crossbars to be ready. The reported illustrative effect is a reduction in peak activated crossbars from 6 to 4 and a peak power reduction of about 30% in that case (Qu et al., 2024).
In the VVM-grained stage, CIM-MLC exploits row-level parallelism through data remapping and finer pipeline scheduling. When only part of a crossbar’s rows can be activated in one cycle, naïve mapping introduces serialization. The WLM stage redistributes data contributing to the same computation across different VXBs or crossbars so that partial row groups can proceed in parallel, allowing downstream operators to begin sooner. This stage is the principal mechanism by which row-activation-limited architectures benefit from the framework.
4. Representative hardware targets and reported performance
CIM-MLC was evaluated on three representative accelerators aligned with its compute modes: an SRAM-based design from Jia et al. that supports CM; PUMA, a ReRAM-based programmable CIM accelerator that supports XBM; and an SRAM CIM macro from Jain et al. with limited simultaneous row activation that supports WLM. The broader experimental infrastructure included a Python-based functional CIM simulator for meta-operator trace checking and an extended performance simulator based on NeuroSim, NVSim, and PUMA-related simulation infrastructure (Qu et al., 2024).
The baseline architecture used in the study was ISAAC-like, with core_number = 768, xb_number = 16, xb_size = [128, 128], parallel row = 8, DAC/ADC = 1/8-bit, Type/Precision = RRAM/2-bit, ALU = 1024 ops/cycle, L0 BW = 384 b, and L1 BW = 8192 b. Benchmarks included VGG series, ResNet series, and ViT, with ImageNet quantized at 8-bit.
The principal quantitative result is an average 3.2× inference speedup over prior CIM-oriented compilation work. More specific comparisons include up to 3.7× speedup against the Jia et al. accelerator, 75% reduction in peak power against PUMA, and about 2.3× speedup against the Jain et al. WLM macro. Against Poly-Schedule, the framework is reported to reduce computation cycles by up to 95% and achieve about 3.2× speedup (Qu et al., 2024).
These gains are not attributed to one optimization layer alone. The data indicate that duplication + pipeline provides the major gain in the Jia et al. case, while VVM-level remapping is decisive for the Jain et al. macro, where MVM-grained optimization alone had limited effect because of the small crossbar count per core. This suggests that CIM-MLC’s main technical contribution lies in exposing and exploiting optimization opportunities that are specific to the hardware tier actually constraining performance.
5. Position within the broader CIM software stack
CIM-MLC occupies the compiler layer of a broader CIM systems stack that also includes training-time quantization, model adaptation, workload partitioning, and architecture-level integration studies. Later work on mixed-precision training and compilation for RRAM-based computing-in-memory accelerators uses a reinforcement learning-based strategy to choose per-layer quantization parameters and a TVM-based compiler to map the resulting model to crossbars, achieving up to a 2.48× speedup over existing state-of-the-art solutions with an accuracy loss of only 0.086% in the best case (Pelke et al., 29 Jan 2026). That work addresses a different layer of the problem: quantization and crossbar slicing overhead, rather than multi-tier scheduling across heterogeneous CIM abstractions.
At the deployment level, heterogeneous CPU–CIM workload partitioning has been formulated as an ILP-based optimization problem that minimizes end-to-end inference latency under RRAM constraints, including limited memory, high write latency, and limited endurance. In that setting, heterogeneous CPU-CIM execution reaches up to 30.9× speedup over CPU-only execution on an edge CPU and 7.3× over a high-performance CPU (Klein et al., 6 Jul 2026). This is complementary to CIM-MLC rather than interchangeable with it: CIM-MLC primarily schedules within the CIM hierarchy, whereas CPU–CIM partitioning determines which operators should run on CIM at all.
Model-level co-design for constrained macros appears in Computing-In-Memory Aware Model Adaption For Edge Devices, which uses a two-stage adaptation pipeline to improve macro usage and quantization robustness, reporting up to 93% compression, up to 256 activated wordlines, and macro utilization up to 94.54% (Lin et al., 16 Oct 2025). Related hardware/software co-design appears in MARS, where structured sparsity and quantization are matched to an SRAM-CIM macro organization, with reported up to 13× speedup and peak estimated energy efficiency of 694 TOPS/W (Sie et al., 2020). At the architecture-evaluation level, WWW: What, When, Where to Compute-in-Memory studies cache-level CiM integration and reports energy-efficiency improvements by up to 3.4× and throughput improvements by up to 15.6× compared to an INT-8 baseline (Sharma et al., 2023).
Taken together, these works place CIM-MLC in a specific niche: it is a middleware and scheduling framework intended to bridge neural-network descriptions and diverse CIM hardware descriptions, rather than a quantization algorithm, a partitioning solver, or a macro-specific model adaptation method.
6. Terminology, misconceptions, and limitations
A recurrent source of confusion is the acronym MLC. In CIM-MLC, it denotes multi-level compilation, not multi-level cell. In the hardware literature, however, MLC frequently refers to multibit device states, as in NASiC, which introduces a 3D NAND-based multibit CIM cell by exploiting MLC Flash states, and UniCAIM, which leverages the multi-level characteristics of FeFETs for signed multibit storage and in-place attention computation (Xu et al., 22 May 2026, Xu et al., 10 Apr 2025). Outside CIM hardware entirely, MLC also denotes multi-label classification, as in ontology-based FAIRification of MLC datasets and benchmark data (Kostovska et al., 2022). The acronym therefore names distinct concepts in separate research programs.
Within its own scope, CIM-MLC has several explicit limitations. Its experiments cover only a few concrete hardware examples, even though the abstraction is presented as broad. Meta-operator support depends on hardware description, so portability still requires users to define supported operations and parameters. The optimization strategy is heuristic / staged rather than a globally optimal formal solver across all levels simultaneously. The evaluation is simulator-based, not based on full chip prototypes, and the crossbar abstraction may simplify variability, device wear, peripheral limits, and calibration issues (Qu et al., 2024).
These limitations do not negate the framework’s significance. They indicate the boundary of what CIM-MLC currently formalizes: a compiler architecture that understands hardware hierarchy and granularity of exposed compute interfaces, and that can exploit CG-grained, MVM-grained, and VVM-grained scheduling opportunities in a unified stack. In that sense, CIM-MLC is best understood as an attempt to make CIM compilation both general-purpose and architecture-aware at the same time (Qu et al., 2024).
