[oharboe]

TL;DR: cleanup with no new code. patches/fakeram/0001 was left over from ORFS's bazel days, and nothing applies it. This PR applies it to tools/FakeRAM2.0, where FakeRAM now lives, and deletes it. Commit 1 is verbatim (there's a one-line check below), and commit 2 is black formatting.

What

This moves code; it adds none. patches/fakeram/0001-Add-ORFS-ASAP7-backend.patch already holds the ASAP7 backend that AUTO_MEMORIES calls (run.py --orfs_asap7_backend, from flow/scripts/memories/gen_memories.py). This PR applies that patch to tools/FakeRAM2.0, where FakeRAM now lives, and deletes the patch file. Code that was a diff in patches/ becomes the files it described.

The diffstat looks bigger than the change because each line appears twice: once removed from the patch file, once added in its real home.

file	what it is
patches/fakeram/0001-...patch (−169)	the patch file, deleted
tools/FakeRAM2.0/orfs_asap7/generate.py (+83)	not new: the patch's own generate.py, unchanged
tools/FakeRAM2.0/orfs_asap7/__init__.py (+1)	the same
tools/FakeRAM2.0/run.py, utils/class_process.py	the patch's hunks for these two files

What the patch brought in but this PR leaves out: its BUILD.bazel and MODULE.bazel, which only made FakeRAM a bazel module.

Why the patch was never applied

The patch dates from when FakeRAM2.0 was a separate repository: ORFS's MODULE.bazel fetched FakeRAM and applied it there. Then FakeRAM moved into tools/FakeRAM2.0 and ORFS dropped bazel. The patch stayed behind with nothing applying it, so run.py in this tree has never known --orfs_asap7_backend.

Commits

1. Apply the patch verbatim and delete patches/fakeram. To check that nothing else changed, run this at that commit; it succeeds:

   git show HEAD^:patches/fakeram/0001-Add-ORFS-ASAP7-backend.patch \
     | git apply -R --check --directory=tools/FakeRAM2.0 \
         --exclude=tools/FakeRAM2.0/BUILD.bazel --exclude=tools/FakeRAM2.0/MODULE.bazel
   

2. black-format the three Python files. The patch predates FakeRAM2.0's black formatting, so its code had never been through black. Formatting only.

Testing

This is the code bazel-orfs has been running AUTO_MEMORIES with. It carries the same patch, re-pathed onto tools/FakeRAM2.0.

The width floor from #4597, and other later backend changes, will follow as ordinary diffs to tools/FakeRAM2.0.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request adds Bazel build configuration, a new orfs_asap7 backend for memory generation, and CLI support in run.py. It also updates the macro dimension calculation in class_process.py to enforce a minimum height constraint. The review feedback recommends specifying utf-8 encoding for all file read/write operations to ensure cross-platform compatibility, and adding defensive checks when parsing the input JSON configuration to prevent potential exceptions.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit a24a1fc · Jenkins build #1 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.

[maliberty]

Where did 3.5 come from?

[oharboe]

Good question. I can't find a source. It came in as a bare literal in the original AUTO_MEMORIES patch (a632406, patches/fakeram/0001), with no rationale. This PR moves it verbatim. Since snap_height_nm = 1400 rounds up after the floor, the effective minimum height is 4.2 µm.

I don't see a PDN reason for a height floor. The macro's M4 power rails are horizontal and the M5 straps are vertical, so strap coverage depends on the macro's width, not its height. That's the floor that will follow (#4597), derived from the 5.4 µm M5 pitch in grid_strategy-M1-M2-M5-M6.tcl. The PDK doesn't expose that pitch to FakeRAM today, so it would be a commented constant next to ASAP7_PROCESS_CONFIG too.

I'd rather keep this PR a verbatim move and decide in a follow-up whether to drop the 3.5 floor or move it into generate.py with a reason. Dropping it changes the generated macros, so it deserves its own diff.

[maliberty]

Fine but please do follow up

[oharboe]

Follow-up: #4608. Nothing in the history explained the 3.5, so the first commit drops it and a forced 4×25 memory fails with "not enough tracks". The second commit sizes the height from the pin count instead: 2 * y_offset + num_pins * pin_pitch.

Other cleanup that came up in the sweep:

• memories: drop the Verilog scanner leftovers, detection is yosys-only #4609 removes what was left of the old Verilog memory scanner; detection is yosys-only.
• docs: AutoMemories views come from FakeRAM2.0's asap7 backend #4610 corrects AutoMemories.md, which described emitters that don't exist.
• memories: run the in-tree FakeRAM2.0, drop FAKERAM_RUN_PY #4611 runs the in-tree FakeRAM2.0 directly, dropping FAKERAM_RUN_PY, which nothing in make set.