OpenGCRAM: Gain Cell RAM Macro Compiler

Updated 6 July 2026

OpenGCRAM is an open-source compiler for Gain Cell RAM, automating the generation of DRC/LVS-clean layouts and SPICE netlists for CMOS foundry processes.
It enables design-space exploration by adjusting parameters like word size, operating voltage, and device flavors to optimize area, delay, and power.
The compiler extends to heterogeneous SRAM+GCRAM macros, supporting AI accelerator designs where memory density and dual-port operation are critical.

Searching arXiv for OpenGCRAM and closely related compiler papers to ground the article. OpenGCRAM is an open-source memory compiler for Gain Cell RAM (GCRAM) that generates GCRAM bank circuit designs, DRC- and LVS-clean layouts for commercially available foundry CMOS, and area, delay, bandwidth, and power characterizations from user-specified configurations such as word size and number of words. In the 2025 formulation, it is presented as a process-compliant, tapeout-ready compiler demonstrated on TSMC 40 nm and positioned for design-space exploration of AI-oriented on-chip memories, particularly where traffic patterns, effective bandwidth, retention time, and leakage power are first-order constraints (Wang et al., 14 Jul 2025). A later extension broadens the same compiler lineage to generate and characterize both SRAM and GCRAM macros for heterogeneous SRAM+GCRAM exploration in AI accelerators (Wang et al., 24 Feb 2026).

1. Definition and scope

OpenGCRAM is defined around Gain Cell RAM, a class of embedded DRAMs that stores charge on an internal storage node and uses a small number of transistors per bit cell. In the 2-transistor form emphasized by the compiler, GCRAM provides higher density than 6T SRAM, lower power with ultra-low leakage, native two-port operation through separate read and write ports, and tunable retention ranging from microseconds to milliseconds and beyond $10$ s depending on device choice and operating conditions (Wang et al., 14 Jul 2025).

The compiler’s stated purpose is to automate a design process that would otherwise be time-consuming and error-prone: circuit generation, layout synthesis, DRC/LVS closure, and timing/area/power characterization of GCRAM banks. Its inputs span logical parameters such as word_size and num_words, device and process choices such as transistor flavor and threshold voltage, operating conditions such as $V_{DD}$ and optional write-wordline level shifting, and peripheral options such as decoders, drivers, sense amplifiers, precharge or predischarge structures, column multiplexers, and control logic. Its outputs include SPICE netlists, GDSII layouts, analytical and HSPICE-based reports, and collateral for integration into EDA flows (Wang et al., 14 Jul 2025).

This positioning makes OpenGCRAM primarily a macro compiler rather than a microarchitectural simulator or a memory-controller framework. Its role is to expose a device–circuit–macro design space in which density, bandwidth, leakage, and retention can be co-tuned against workload demands. The later heterogeneous-memory work preserves that role while extending the target set to 6T SRAM and mixed SRAM+GCRAM compositions for AI accelerators (Wang et al., 24 Feb 2026).

2. Gain-cell memory model and circuit basis

OpenGCRAM is organized around the circuit semantics of 2T GCRAM cells. In the Si-Si variant, the bitcell has separate write wordline $WWL$ , write bitline $WBL$ , read wordline $RWL$ , and read bitline $RBL$ ; the storage node is charged or discharged through the write transistor and sensed through the read transistor. In the OS-OS variant, both devices are n-type oxide-semiconductor transistors and the design targets ultra-low leakage retention with single-ended read (Wang et al., 14 Jul 2025).

The peripheral architecture is correspondingly specialized. The compiler instantiates or generates Write_Port_Address and Read_Port_Address decoders, Write_Port_Data and Read_Port_Data interfaces, single-ended sense amplifiers with an on-chip reference generator, predischarge or precharge structures depending on the read topology, Data_DFFs, and independent read and write enable logic. Column multiplexers may be inserted to “squarify” arrays under particular word_size:num_words choices (Wang et al., 14 Jul 2025).

Several operation-level subtleties are central to OpenGCRAM’s design space. In NMOS-NMOS Si-Si GCRAM, an active-low $RWL$ can capacitively couple into the storage node and degrade the stored value, compounding write-wordline coupling. Complementary NMOS-PMOS read/write arrangements mitigate this by allowing active-high read events to boost the storage node. Raising $WWL$ above $V_{DD}$ with a write-wordline level shifter $WWLLS$ can increase the storage-node high level toward $V_{DD}$ 0, improving read margin and read speed at the cost of extra supply routing and area (Wang et al., 14 Jul 2025).

The compiler is framed by several derived models that organize interpretation of the generated macros. The first-order delay approximations are

$V_{DD}$ 1

and

$V_{DD}$ 2

Dynamic energy per access is approximated as

$V_{DD}$ 3

while retention is summarized by

$V_{DD}$ 4

The coupling-induced read disturb on the storage node is modeled as

$V_{DD}$ 5

These expressions are explicitly described as derived rather than as the source of reported numerical results (Wang et al., 14 Jul 2025).

3. Compiler organization and generated artifacts

OpenGCRAM’s flow begins with parameter parsing and proceeds through cell and peripheral instantiation, netlist generation, layout synthesis, DRC/LVS closure, and HSPICE-based characterization. The inputs include memory size and aspect, device flavor such as Si-Si or OS-OS, threshold-voltage selections for read and write devices, $V_{DD}$ 6, $V_{DD}$ 7 enablement, sense-amp and precharge/predischarge choices, and the target operating point. The compiler integrates custom core modules such as the bitcell, write driver, sense amplifier, and DFF with automatically generated modules such as decoders, wordline drivers, muxes, reference generator, and control logic. Driver sizing is guided by OpenRAM’s methodology based on logical effort and path delay estimates (Wang et al., 14 Jul 2025).

The layout stage connects wordlines, bitlines, control nets, and data pins and emits per-bank GDS with power rings, including an additional ring when $V_{DD}$ 8 is enabled. DRC and LVS are then closed by refining the Python layout generation for spacing, width, enclosure, and extension rules. The output artifacts are stated to be tapeout-ready for TSMC 40 nm, with all DRC/LVS errors resolved for bank capacities from 256 bits to 16 Kb (Wang et al., 14 Jul 2025).

The following table summarizes the compiler’s principal I/O categories.

Category	Examples stated in the source	Generated result
Logical configuration	`word_size`, `num_words`, bank size, porting	Bank topology and organization
Device/process configuration	TSMC 40 nm, Si NMOS/PMOS, OS n-type, `LVT/SVT/HVT`	Process-compliant netlists and layouts
Operating/periphery options	$V_{DD}$ 9, `WWLLS`, decoders, drivers, sense amps, muxes	Characterized timing, power, shmoo plots
Signoff outputs	HSPICE stimuli, tech files, DRC/LVS rules	DRC- and LVS-clean GDSII, SPICE collateral

The implementation environment is partly open and partly constrained by foundry NDAs. The repository is open-source, but the TSMC technology script and proprietary custom cells are excluded under NDA. HSPICE is used for transistor-level simulation and characterization, and the paper states that the methodology is general enough to be ported to other nodes such as TSMC 16 nm and to other memory types such as DRAM and RRAM (Wang et al., 14 Jul 2025).

4. Quantitative properties and design trade-offs

OpenGCRAM’s design space is defined by density, frequency, effective bandwidth, leakage, and retention. In TSMC 40 nm, the 2T Si-Si GCRAM cell occupies $WWL$ 0 of the area of a 6T SRAM cell, corresponding to a $WWL$ 1 reduction, while a 2T OS-OS GCRAM cell occupies $WWL$ 2 of the SRAM cell area, corresponding to an $WWL$ 3 reduction. At bank level, Si-Si arrays are smaller than SRAM arrays, but dual-port Si-Si banks can initially have larger total area than single-port SRAM because periphery dominates at small sizes; polynomial trend extrapolation indicates the GCRAM bank becomes smaller beyond approximately $WWL$ 4 Kb as periphery is amortized. OS-OS banks are smaller than SRAM banks because only periphery consumes Si area when the cell is built in BEOL and monolithically 3D-stacked (Wang et al., 14 Jul 2025).

The frequency trade-off is less favorable than the area trade-off. Read limits the maximum operating frequency for both SRAM and GCRAM, but Si-Si GCRAM has lower operating frequency than SRAM for matched configurations, primarily because of single-ended read. $WWL$ 5 improves GCRAM read frequency, and array organizations that avoid column muxing, such as word_size:num_words = 4:1, achieve higher frequency than 1:1 at the same bank size. Additional delay-chain stages in the read controller can further reduce frequency as bank size grows (Wang et al., 14 Jul 2025).

Effective bandwidth is represented by

$WWL$ 6

which highlights one of GCRAM’s key architectural advantages: native dual-port operation. Because read and write are decoupled, dual-port GCRAM can sustain simultaneous read and write, whereas traditional single-port SRAM must serialize or share the same port, effectively halving per-direction bandwidth when both are active (Wang et al., 14 Jul 2025).

Leakage is one of the strongest differentiators. The bitcell has no direct $WWL$ 7-to-GND path, so cell leakage is negligible relative to SRAM, and OS-channel devices achieve off-state leakage below $WWL$ 8 A/ $WWL$ 9m. Compiler-generated HSPICE simulations are reported to confirm significantly lower leakage for GCRAM banks. For short-lived caches, external profiling cited in the source indicates that Si-GCRAM reduces active energy by $WBL$ 0– $WBL$ 1 versus SRAM (Wang et al., 14 Jul 2025).

Retention is explicitly tunable. Simulations show microsecond-level retention for Si-Si, with enhancement through higher $WBL$ 2 and $WBL$ 3, and millisecond-level retention for OS-OS; with higher OS $WBL$ 4, retention exceeding $WBL$ 5 s is described as feasible. This makes threshold-voltage choice, channel material, and operating voltage central optimization variables rather than secondary implementation details (Wang et al., 14 Jul 2025).

5. Role in AI-oriented design-space exploration

OpenGCRAM is explicitly motivated by the “memory wall” in AI systems, where on-chip memory capacity and bandwidth often constrain performance more than arithmetic throughput. The compiler is therefore coupled to workload-facing exploration rather than treated purely as a memory-generation backend. The source describes profiling of cache demands for 2D and 3D convolutions, ResNet-18, BERT-110M, Stable Diffusion-3.5B, and LLaMA variants, with the GainSight framework used to extract L1 and L2 requirements (Wang et al., 14 Jul 2025).

The central methodology is to intersect a task’s required read frequency and data lifetime with the characterized capability region of each memory type. Short-lived data such as activation caches and scratchpads are mapped toward Si-Si GCRAM with modest $WBL$ 6 and higher $WBL$ 7 for speed. Long-lived data such as model weights or L2 entries for diffusion workloads are mapped toward OS-OS GCRAM with higher $WBL$ 8 and possibly lower $WBL$ 9 for retention. When multiple configurations meet a task’s performance target, larger banks are preferred for higher bandwidth and effective density. Multi-banked GCRAM is identified as a natural design for serving many parallel requests, although single-banked generation is the present compiler focus (Wang et al., 14 Jul 2025).

The 2026 heterogeneous-memory extension generalizes this workflow by placing 6T SRAM, 2T Si-Si GCRAM, and 2T OS-Si GCRAM in a common compiler and characterization flow. In that formulation, OpenGCRAM generates DRC/LVS-clean layouts and SPICE netlists for all supported macro types, plus .lib, .lef, and Verilog for SoC integration, and is used to identify feasible SRAM+GCRAM compositions for AI tasks under bandwidth, retention, and area constraints. That work reports, for example, that Si-Si GCRAM bank area becomes smaller than single-port SRAM above $RWL$ 0 Kb and that OS-Si GCRAM banks are the smallest across the full tested size range (Wang et al., 24 Feb 2026).

A plausible implication is that OpenGCRAM is most valuable when workload characterization is available at the reuse-distance or lifetime level rather than only at the aggregate bandwidth level. The source repeatedly ties configuration choices to the joint distribution of frequency demand, lifetime demand, and bank organization, rather than to a single scalar metric (Wang et al., 14 Jul 2025).

6. Naming, relation to other tools, and limitations

OpenGCRAM should not be conflated with unrelated uses of similar acronyms. The provided materials include an “open-source RRAM compiler” described generically rather than explicitly branded as OpenGCRAM (Antoniadis et al., 2021), a hardware memory-compression design called CRAM (Young et al., 2018), and an OpenGL GPU-based Rowhammer work whose details interpret “OpenGCRAM” in a completely different sense (Plin et al., 24 Sep 2025). Within the gain-cell-memory literature, however, the term specifically denotes the open-source GCRAM compiler introduced in 2025 and extended in 2026 (Wang et al., 14 Jul 2025).

The most important practical limitation is performance asymmetry versus SRAM. Si-Si GCRAM read frequency is lower than SRAM because of single-ended sensing, and frequency can fall as bank size increases unless the macro is carefully organized to avoid column muxes and poorly tuned delay chains. Dual-port periphery also increases area at small capacities, even though the array itself is denser. Retention remains sensitive to threshold-voltage distributions, temperature, and process variation, and the 2025 paper emphasizes precise HSPICE simulations without reporting Monte Carlo results (Wang et al., 14 Jul 2025).

The current compiler scope is also constrained. The present flow focuses on single-banked instances; multi-bank generation is explicitly future work. Hybrid Si-OS GCRAM is proposed as a future extension to occupy intermediate frequency–retention points. Current-mode sense amplifiers, more advanced nodes such as 16 nm, precise HSPICE characterization of OS-OS banks, and ML-based area–delay–power co-optimization are likewise listed as future directions (Wang et al., 14 Jul 2025).

In the heterogeneous-memory extension, additional omissions are stated directly: there is no explicit PVT-corner coverage, variability or yield modeling, retention distributions versus process or temperature, explicit refresh controller or refresh-energy accounting, or formal optimization solver. Selection across SRAM and GCRAM types is rule-based, using feasibility first and efficiency second (Wang et al., 24 Feb 2026).

Taken together, these constraints place OpenGCRAM in a specific niche: it is a process-aware macro compiler and exploration framework for gain-cell memories, not a complete signoff methodology for all variability questions and not a full system-level memory-management stack. Its significance lies in making GCRAM macro generation, characterization, and workload-matched exploration reproducible and open enough for academic and early-stage industrial research (Wang et al., 14 Jul 2025).