1 Introduction↩︎

Memory inference remains a significant challenge in turnkey ASIC design flows. Inferring flip-flops from RTL can create thousands of densely interconnected instances which dramatically slow down design flows and impede performance. Memory compilers address this issue, although they are third-party tools which are often PDK-specific and may require specialized cells not in the base PDK.

To address these shortcomings, we present ORRAM, a standard-cell-based memory generator built as a native module within OpenROAD. Given a standard cell library, ORRAM produces a fully placed and routed RAM block requiring no custom bitcells or external tooling, with timing verification via OpenSTA rather than SPICE simulation. ORRAM supports arbitrary word sizes, word counts, mask granularities, multi-port read configurations, column muxing, latch-based storage, and automatic PDK-agnostic cell selection, making it compatible with most standard cell libraries including sky130hd and NanGate45. Evaluated on SkyWater 130nm, ORRAM matches the bit density of historical DFFRAM results while offering a significantly expanded feature set. The source code is available as part of the OpenROAD project [1].

2 Related Work↩︎

Several open-source alternatives exist for generating on-chip memories, however they each have shortcomings for designers seeking high productivity with low barrier to entry. The primary option for digital designers is to declare the memory in RTL, which will be inferred as flip-flops during synthesis and then placed and routed with other logic. Open-source tools like Yosys [2] and OpenROAD [3] handle this methodology; however, this technique can incur a high power/performance/area (PPA) penalty due to synthesis algorithms which do not infer buses and generic placement algorithms that reduce logic utilization. Further, runtime of the overall digital flow is impacted by inserting thousands – possibly millions – of cells into the netlist and slowing down optimization algorithms.

In contrast, memory compilers can alleviate many of the PPA and runtime issues by generating the memory as a block. OpenRAM [4] is an open-source SRAM compiler that constructs high-density SRAM arrays; however, it requires designing custom cells like 6T bitcells and sense amplifiers for each PDK being targeted. Further, it requires expensive SPICE simulations for power and timing info.

DFFRAM [5] instead takes a standard-cell-based approach, constructing RAM arrays from flip-flops/latches and associated logic without requiring custom bitcell design. Previous versions achieved high bit densities through a custom placer. However, DFFRAM now only generates netlists and instead relies on LibreLane [6] for placement and routing, resulting in significantly lower densities.

ORRAM addresses these limitations by taking a fully integrated approach to standard cell memory generation within OpenROAD. Rather than operating as a standalone compiler, ORRAM [1] generates a fully placed and routed memory block as a native OpenROAD module and performs timing verification via OpenSTA instead of SPICE simulation.

3 Features and Implementation↩︎

¹

RAM Structure. ORRAM’s default memory architecture consists of an input buffer stage, a word decoder, and a storage array (Fig. 1). Input buffers drive data signals into the high-fanout core array, while word selection is handled by a decoder. One decoder is generated per RAM port, generating per-word write enable and per-port read select signals. The array is composed of flip-flops/latches, with tristate cells gating each word’s output onto a shared read bus.

Column muxing. Column muxing enables changing the aspect ratio of a RAM by placing multiple words per physical row. This is useful for typical memories which have much larger word counts than word sizes. ORRAM supports a column_mux_ratio of {1, 2, 4}, which corresponds to the number of words per physical row. For each physical row, words are interleaved such that each bit is adjacent as shown in Fig. 4. A row of multiplexers is created at the top of the array using AOI22 bit cells, which are generally available in any standard cell library. The lowest \(\log_2(\texttt{column\_mux\_ratio})\) bits of the address select the word within a row, and the remaining upper bits select the physical row.

Latch memory support. Latch-based memories have considerable advantages over flip-flop-based memories, offering a compact, faster, and more power-efficient alternative. ORRAM offers the option to use latches as storage cells through a two-phase latch setup. When enabled, a row of negative latches is inserted between the input buffer and the storage rows, which now consist of positive latches. During the low clock phase, the negative latch in each column captures and holds the input data; on the rising edge, the positive latches in the cells below capture this data, thus having identical functionality to a positive flip-flop. With column muxing enabled, the negative latch position within each bit group is adjusted to maintain balanced fanout across all storage cells below.

Behavioral Model. ORRAM supports generatiion of a cycle-accurate, PDK-agnostic behavioral model for all configurations. This behavioral model can be used in RTL simulations for significantly faster simulation than simulating directly with the netlist.

4 Results and Takeaways↩︎

5pt

We evaluated ORRAM on sky130hd across a range of memory sizes from 512 bytes to 8 KB, compared to other current open-source alternatives. All configurations target 64-bit word reads with byte-level write masking (Table 1).

ORRAM’s DFF-based memory achieves bit densities of approximately 28,000 bits/mm\(^2\) across all tested sizes, representing roughly 2× the density of the current DFFRAM project, which achieves approximately 14,000–15,000 bits/mm\(^2\) across the same configurations. This gap stems from DFFRAM relying on LibreLane for placement and routing using generic algorithms, whereas ORRAM uses OpenROAD’s API to create a custom placer and enable much higher placement regularity and density. Notably, historical DFFRAM results using its deprecated custom placer achieved approximately 26,000–26,500 bits/mm\(^2\), which ORRAM’s DFF-based approach matches while offering a significantly expanded feature set. By comparison, the behavioral RTL approach that uses OpenROAD Flow Scripts (ORFS) achieves approximately 15,000–15,600 bits/mm\(^2\), and additionally incurs the overhead of executing the full RTL-to-GDS flow including synthesis, clock tree synthesis, and general-purpose placement and routing. OpenRAM achieves higher peak densities at larger sizes (up to \(\sim\)​148,000 bits/mm\(^2\) at 8 KB) due to its custom 6T bitcell layouts, but comes with the need for hand-designed cells for each target PDK and cumbersome SPICE simulations to measure timing.

ORRAM’s latch-based memory provides a 15% density improvement over its DFF counterpart, achieving 31,000–32,000 bits/mm\(^2\) across tested sizes due to the smaller footprint of latch cells relative to flip-flops, with the trade-off of additional timing analysis complexity due to the two-phase capture behavior. For designs where latch-based timing closure is acceptable, this configuration offers the highest density of any standard-cell-based approach evaluated.

Beyond density, ORRAM provides several capabilities absent from the current DFFRAM project: multi-port read/write configurations, configurable column muxing for aspect ratio control, and native integration within OpenROAD and OpenROAD Flow Scripts. Combined, these features make ORRAM a drop-in memory generation solution for open-source ASIC design without requiring custom bitcell libraries or an external flow setup.

5 Future Work↩︎

While ORRAM already offers many features to support faster design space exploration and even tapeouts, we are still working on several features to improve usability and performance including: 1) tightly integrating OpenSTA to perform timing and power-based optimization on RAM configurations, 2) banking support to help support even larger-scale RAMs, and 3) automatically generating RAMs from the memory inference step during synthesis.

References↩︎