---
title: 'OpenACM: Open-Source DCiM Compiler'
url: https://www.emergentmind.com/topics/openacm
type: topic
---

# OpenACM: Open-Source DCiM Compiler

OpenACM is an open-source framework for SRAM-based approximate compute-in-memory, presented initially as the **first open-source, accuracy-aware compiler for SRAM-based approximate digital compute-in-memory (DCiM) architectures**. Its purpose is to automate the generation of DCiM macros while exposing application-level error tolerance as a hardware design variable, rather than constraining the toolchain to exact arithmetic. In the cited literature, OpenACM combines an integrated multiplier library, a transistor-level customizable SRAM macro, variation-aware characterization, and a complete open-source physical design flow based on OpenROAD and FreePDK45; subsequent work extends the framework with compiler-integrated floating-point multiplication and with a broader **Accuracy-Constrained Co-Optimization (ACCO)** methodology embodied in OpenACMv2 [2601.11292] [2606.08430] [2603.13042].

| Paper | Focus | Reported headline |
|---|---|---|
| "OpenACM: An Open-Source SRAM-Based Approximate CiM Compiler" [2601.11292] | Open-source, accuracy-aware approximate DCiM compilation | Up to 64% energy savings with negligible loss in application accuracy |
| "Accuracy-Configurable Floating-Point Multiplier Design for SRAM-Based Compute-in-Memory" [2606.08430] | Floating-point multiplier integrated into OpenACM | Up to 69% logic area reduction and 72% power savings over exact floating-point designs without delay overhead |
| "OpenACMv2: An Accuracy-Constrained Co-Optimization Framework for Approximate DCiM" [2603.13042] | ACCO and two-level optimization for approximate DCiM | GNN-based surrogate plus variation- and PVT-aware sizing for rapid what-if exploration |

## 1. Definition and problem setting

OpenACM is motivated by the “memory wall” problem in AI hardware. The framework adopts the DCiM premise that moving data between memory and compute dominates energy and latency in conventional von Neumann systems, and it treats SRAM-based DCiM as a scalable response. Its distinctive claim is that many AI workloads, especially neural networks, can tolerate arithmetic approximation, so a compiler for DCiM should not be restricted to exact datapaths. On that basis, OpenACM was developed to bridge **application-level error tolerance** and **hardware-level automation**, while also removing dependence on proprietary EDA tools through an explicitly open stack [2601.11292].

The initial formulation emphasizes two deficiencies in prior DCiM compilers. First, they focus on exact arithmetic, even though approximation can improve energy efficiency. Second, they are not sufficiently open and reproducible for broad academic use. OpenACM therefore exposes multiplier-level approximation as a first-class design choice and compiles those choices into a physical implementation. A plausible implication is that OpenACM shifts approximate DCiM from ad hoc circuit design toward a compiler-mediated design space in which accuracy, energy, and area are co-optimized rather than evaluated post hoc.

## 2. End-to-end compiler organization

The original OpenACM compiler is organized into four major parts: a **Processing Element (PE) compiler**, a **Multiplier compiler**, an **SRAM macro compiler**, and a **Flow-script generator**. Together, these convert user specifications into a physically implemented DCiM macro. The user specifies SRAM organization and multiplier configuration; the compiler then generates an SRAM behavioral model, LEF abstract, LIB timing/power/area views, RTL for control and arithmetic logic, and OpenROAD backend scripts. OpenROAD performs synthesis, placement, routing, and signoff analysis, producing the final CiM macro and associated artifacts [2601.11292].

This flow is notable because it goes beyond coarse precision scaling. The architecture space includes multiplier family selection, approximate-compressor placement, SRAM organization, and backend integration. The paper frames this as necessary because the DCiM design space is too large for manual exploration. In that sense, OpenACM functions not merely as a library of circuit blocks, but as a compiler that resolves high-level configuration choices into a concrete memory-compute macro.

## 3. Approximation mechanisms and multiplier library

A central contribution of OpenACM is its integrated library of **accuracy-configurable multipliers**. The initial paper describes three multiplier families: an **exact 4-2 compressor-based multiplier**, a **tunable approximate 4-2 compressor multiplier**, and a **logarithmic multiplier**. The exact design provides the correctness-preserving baseline. The approximate 4-2 design replaces some exact compressors with approximate 4-2 compressors, typically in lower-order partial-product columns, enabling fine-grained tuning through the choice of which compressor cells and bit-columns are approximate. The logarithmic multiplier is based on **Mitchell’s Algorithm**, using leading-one detection, shifting, addition/subtraction, and optional error compensation; OpenACM’s version introduces a **dynamic compensation strategy** intended to reduce arithmetic error [2601.11292].

The paper describes these families as spanning a spectrum. Exact multipliers maximize fidelity; approximate 4-2 designs provide moderate approximation with controllable degradation; logarithmic multiplication offers the strongest energy reduction, especially at larger bit widths, when more error is acceptable. For evaluation, the framework uses **NMED** and **MRED** as arithmetic error metrics, alongside post-layout area, delay, and power. This organization makes multiplier choice part of the compiler-visible architecture rather than a fixed implementation detail.

The initial paper also states that support for native floating-point operations was not yet implemented. That limitation is historically important because later work turns floating-point multiplication into a first-class OpenACM operator. This suggests a staged evolution in which the framework first established an open approximate integer/fixed-point DCiM flow and then expanded toward broader arithmetic coverage.

## 4. SRAM macro generation and open physical-design infrastructure

OpenACM includes a **transistor-level customizable SRAM macro** implemented as a compact, banked, subarrayed **6T SRAM** with hierarchical word-line decoders and drivers, precharge circuitry, write drivers, optional column multiplexers, and differential sense amplifiers. The macro is not treated as a fixed black box: the compiler exposes rows, columns, word width, bank/subarray count, column mux ratio, and timing controls such as precharge and sense-enable as design knobs. This allows memory organization to be co-optimized with approximate arithmetic [2601.11292].

A further distinguishing feature is **variation-aware characterization**. Built on **OpenYield**, the flow uses Monte Carlo SPICE simulations with process variation and **importance sampling** to estimate distributions for access latency, read/write/hold SNM, and dynamic and leakage power. The emphasis is that SRAM correctness and yield are too sensitive to variation for idealized characterization to suffice. Importance sampling is used to reduce simulation count while preserving accuracy at the target yield.

At the backend, OpenACM relies on **OpenROAD** and **FreePDK45**, explicitly to remove dependencies on proprietary EDA tools and to improve reproducibility and accessibility. During place-and-route, the SRAM is integrated as a **black-box hard macro** using a FakeRAM2.0-style interface. The paper is explicit that the exact SRAM GDS/layout generation was not yet complete in the initial release, even though the abstract views were sufficient for integration. That limitation places OpenACM in a transitional position: operational as an open research flow, but still incomplete as a fully automated end-to-end memory-layout generator.

## 5. Empirical results and application-level behavior

The original evaluation uses FreePDK45, OpenROAD, and Xyce, with post-layout measurements at **100 MHz** and **0.5 pF output load**. The paper reports that delay remains roughly constant around **5.2 ns** across designs, which it interprets as evidence that SRAM dominates timing. Within that regime, approximate designs reduce logic area and power, and logarithmic multipliers become more advantageous as bit width increases. For **32×16**, the logarithmic design cuts logic area by **33%**; for **64×32**, logic area reduction reaches **51%**. In the same **64×32** case, the logarithmic design reduces power by **nearly 64%** compared with the exact multiplier. The approximate 4-2 design yields up to **14% power savings** at **16×8**. The headline result is **up to 64% energy savings** with negligible loss in application accuracy [2601.11292].

Application-level evaluation covers **image blending**, **edge detection**, and **ResNet-18** on **ILSVRC2012**. In image-processing experiments, the paper states that Appro4-2 achieves high PSNR and can replace exact multipliers effectively, while Log-our significantly outperforms conventional Mitchell LM. For example, in image blending, conventional LM often falls below **30 dB**, whereas Log-our exceeds **30 dB**; in edge detection, Log-our often reaches the **40 dB+** range, which the paper associates with near-identical quality. On ResNet-18, **Appro4-2** reports **Top-1: 0.668 vs 0.677 exact**, **Top-5: 0.880 vs 0.873 exact**, with **17%** power savings. **Log-our** reports **Top-1: 0.680 vs 0.677 exact**, **Top-5: 0.870 vs 0.873 exact**, with **64%** power savings. Conventional LM shows substantially worse accuracy, with **Top-1: 0.610** and **Top-5: 0.842**.

These results are presented not as a universal argument for aggressive approximation, but as evidence that the form of approximation matters. The paper attributes Log-our’s favorable behavior partly to its bidirectional error profile, which it interprets as more noise-like than the error induced by conventional logarithmic multiplication.

## 6. Floating-point extension inside OpenACM

Later work extends OpenACM to support **both exact IEEE 754 floating-point multiplication and an accuracy-configurable approximate floating-point multiplier (AFPM)**, making floating-point arithmetic a **first-class, compile-time selectable operator** within the DCiM flow [2606.08430]. The exact baseline follows the standard IEEE 754 structure: sign generation, exponent accumulation and bias correction, mantissa multiplication, normalization, and rounding/exception handling. A normalized value is written as
$$
V = (-1)^S \times (1.M) \times 2^{E-\text{Bias}}.
$$

The proposed AFPM is based on **mantissa segmentation**, partial-product pruning, conditional execution of lower-significance cross-products, and lightweight compensation. For FP32, the 23-bit explicit mantissa is partitioned into high- and low-significance segments with configurable segment width \(n\). The dominant high-order product is computed exactly, while lower-weight terms may be bypassed or approximated. The paper also introduces a more aggressive low-complexity mode called **ACL5**, where only the highest \(n\)-bit segments are used and their bitwise AND supplies a first-order approximation.

Post-layout results show **up to 69% logic area reduction and 72% power savings over exact floating-point designs without delay overhead**. The same paper reports that **ACL5** gives **78.4% logic area reduction** and **82.1% power reduction** relative to the exact multiplier in one configuration, while delay remains unchanged because the critical path is still SRAM-dominated. Image-processing experiments report PSNR values that increase with larger segmentation width, with several configurations exceeding **80 dB** on edge detection. On **ResNet-18** inference on **CIFAR-10**, the exact baseline achieves **Top-1 = 0.8715** and **Top-5 = 0.9961**. The proposed **AC4-4**, **AC5-5**, and **AC6-6** variants preserve Top-1 and Top-5 essentially unchanged, whereas more aggressive designs such as **ACL5** trade some accuracy for lower hardware cost. The paper’s broader claim is that floating-point support in SRAM-based DCiM becomes practical when approximation is exposed as a compiler knob rather than forced into a rigid exact datapath.

## 7. OpenACMv2 and Accuracy-Constrained Co-Optimization

OpenACMv2 generalizes the original compiler into an **accuracy-constrained co-optimization framework** called **ACCO**, implemented as a two-level workflow [2603.13042]. Level 1 performs **accuracy-constrained architecture search** over approximate multipliers and SRAM macro organization, using a GNN-based surrogate called **PEA-GNN** to predict error and PPA rapidly. Level 2 performs **variation- and PVT-aware transistor sizing** for both compressor implementations and SRAM bitcells, using Monte Carlo SPICE and worst-case aggregation across corners.

The architecture-search formulation makes application error explicit. For an architecture vector \(\mathbf{a}\), the paper defines
$$
\text{MRED}(\mathbf{a}) = \frac{1}{|\mathcal{U}_+|} \sum_{(x,y)\in\mathcal{U}_+} \frac{\operatorname{ED}_{\mathbf{a}}(x,y)}{R_{\text{exact}}(x,y)},
$$
and
$$
\text{NMED}(\mathbf{a}) = \frac{1}{|\mathcal{U}|} \sum_{(x,y)\in\mathcal{U}} \frac{\operatorname{ED}_{\mathbf{a}}(x,y)}{R_{\max}},
$$
with a top-level optimization of minimizing \(\text{MRED}\) and \(\operatorname{PDP}\) subject to an \(\text{NMED}\) constraint. The multiplier design space is combinatorial: for an \(N\)-bit multiplier, the paper defines \(t=9\) configurable compressor positions and a library of \(K=8\) compressor types, giving a search space of \(8^9\).

The surrogate model is intended to make that search practical. For **8-bit** designs, the paper reports **MRED/NMED prediction error: about 2.1% / 1.8%**, **Delay/Area/Power errors below 0.3%**, and runtime of **0.26 s** with the GNN versus **37 s** with EDA, or about **142× speedup**. For **16-bit** designs, it reports **MRED/NMED error: about 4.7% / 2.3%**, **PPA deviations below 0.25%**, and runtime of **0.25 s** versus **116 s**, or about **464× speedup**. Among the top-level optimizers, **MOEA/D** is reported as the most stable. At the lower level, transistor sizing further reduces PDP while keeping MRED fixed, whereas for SRAM the paper concludes that macro organization tends to dominate the PPA outcome more strongly than bitcell-level tuning.

OpenACMv2 therefore reframes OpenACM from a compiler that instantiates configurable approximate DCiM macros into a broader optimization environment for structured “what-if” exploration under explicit accuracy budgets. A plausible implication is that the framework’s center of gravity has shifted from open implementation alone to open, reproducible design-space exploration in which compiler choices, surrogate modeling, and circuit robustness are treated as parts of one workflow.

Source: https://www.emergentmind.com/topics/openacm