Can mock ASAP7 .lib and .lef files be generated?

[oharboe]

For architectural exploration, I would like to have idiomatic .lib, .lef and behavioral logic .v files?

I realize asap7 is missing the fiddlybits to create actual .gds files, but that isn't needed for architectural exploration, I just need to know I'm modelling with .lib and .lef files which are idiomatic in area, timing and behavioral model for ASAP7.

Is this viable?

I'm interested in having a go at wiring this up to https://github.com/The-OpenROAD-Project/bazel-orfs with the help of Claude, but I need some domain knownledge constraints.

[oharboe]

OpenRAM ASAP7 LEF/LIB for Architectural Exploration — Integration Context

What I'm trying to do

I maintain bazel-orfs, the Bazel build rules for the OpenROAD RTL-to-GDS flow. I'd like to wire OpenRAM into bazel-orfs so that users can generate SRAM macros as a build step — the flow would invoke OpenRAM to produce .lef and .lib files, then feed them directly into OpenROAD place-and-route.

For architectural exploration, I don't need GDS — just LEF (physical outline + pin geometry) and LIB (Liberty timing model) that are realistic for ASAP7. A behavioral Verilog model (.v) would also be useful for simulation.

What bazel-orfs already supports

bazel-orfs has a memory maturity ladder for SRAM integration:

Level	Approach	Area	Timing
0	Yosys mocks large memories inline	Wrong	Wrong
1	Behavioral RTL synthesized as macro with mock_area	Approximate	Wrong
2	+ SDC constraints on memory interfaces	Approximate	Paths correct
3	Mock areas calibrated against SRAM compiler output	Near-accurate	Near-accurate
4	Real SRAM compiler LEF/LIB/GDS	Correct	Correct

Levels 0–3 work today. Level 4 is documented but has no actual SRAM compiler integration yet. OpenRAM would be the first.

The integration would look something like this in a user's BUILD file:

# Hypothetical — generate SRAM macro via OpenRAM
openram_sram(
    name = "sram_256x32",
    word_size = 32,
    num_words = 256,
    technology = "asap7",
)

# Use it as a macro in an OpenROAD flow
orfs_flow(
    name = "my_design",
    verilog_files = [":rtl"],
    macros = [":sram_256x32"],  # consumes the LEF/LIB
    ...
)

Under the hood, openram_sram would invoke OpenRAM's compiler and extract the LEF + LIB (+ behavioral Verilog) outputs.

Questions for OpenRAM experts

1. ASAP7 viability

The issue title asks about ASAP7. I understand ASAP7 is missing some of the foundry-specific data needed for full GDS generation.

• Can OpenRAM produce LEF and LIB for ASAP7 today? Even without GDS, are the cell characterization and layout abstraction paths functional enough to generate realistic timing models and physical outlines?
• If not fully supported, what's the gap? Is it missing technology files, SPICE models, characterized cells, or something else?
• My interest is ASAP7 idiomatic memory modelling, but building on this work, perhaps other PDKs could follow

2. Invocation and outputs

I need to understand the compiler interface to wrap it in a Bazel rule:

• What is the minimal command to generate LEF + LIB? Something like:

  python3 sram_compiler.py -t asap7 -s 32 -w 256 -o /output/dir

  What are the actual flags? Can GDS generation be skipped to save time?

• What files are produced? I expect at minimum:

  • sram_256x32.lef — physical abstract
  • sram_256x32.lib — Liberty timing model
  • sram_256x32.v — behavioral Verilog

  Are there others? What's the naming convention?

• What environment is needed? I see OPENRAM_HOME and OPENRAM_TECH environment variables. Are there runtime dependencies beyond Python (SPICE simulator, Magic, etc.)? For LEF/LIB-only generation, can those be skipped?

• How long does a single SRAM compilation take? Seconds? Minutes? This affects whether we can generate on-the-fly in a build or need to pre-generate and cache.

3. Configuration space

For architectural exploration, users want to sweep SRAM configurations:

• What word_size × num_words combinations are valid for ASAP7? Are there power-of-2 constraints, minimum/maximum sizes?
• Can port configurations be specified? (1RW, 1R1W, 2RW, etc.)
• Are there PVT corner options? For Liberty models, we'd want at least a typical corner, ideally fast/slow too.

What I can contribute

On the bazel-orfs side, I can implement:

1. A Bazel repository rule that downloads/provisions OpenRAM (similar to how we handle OpenROAD via Docker image extraction)
2. A openram_sram() Bazel rule that invokes the compiler and exposes LEF/LIB/Verilog as build outputs
3. Integration tests using the existing sram/ test directory in bazel-orfs
4. Documentation for the memory maturity ladder (Level 4)

What I need from the OpenRAM side is guidance on questions 1–3 above, and ideally a working ASAP7 example I can test against.

Related

• bazel-orfs memory macro rule: orfs_macro()
• Existing fakeram test: sram/BUILD — shows the LEF/LIB consumption pattern
• Memory strategy docs: gallery/docs/adding-projects.md

[mguthaus]

Anything is viable. I've had it listed as a project for 5+ years but nobody has been willing to help. Early on, ASAP7 had some issues with distributing their PDK and I'm not sure that has been resolved.

ASAP7 comes with some bitcells and using those would be the most challenging. I haven't looked closely.

This is specifically some of the spacial reasoning that LLMs really struggle with, for now.

[mguthaus]

I don't have any bandwidth to support this but am willing to accept PRs if they don't break anything.

1. Unless you have full GDS and extraction, results will be no better than other mock memory models. Getting to this point, is significant work. Each technology has new idiosyncrasies and ASAP7 would be the first FINFET technology supported. This would creep into everything from netlist to layout.

2. This is all available in the documentation:
   https://github.com/VLSIDA/OpenRAM/blob/stable/docs%2Fsource%2Findex.md

Compile times depend on accuracy. For the highest accuracy, we require extraction and simulation which can take hours, even days. Using mock models, it can take seconds but, as mentioned above this is not accurate.

3. Our general approach for configurations is that we allow anything, but it may break. Power of 2 is included in this. Port configurations of 2 are supported physically, but more than 2 only in netlists. Corners are supported.