FakeRAM2.0: known problems with the asap7 macros AutoMemories generates #4613

Description

AutoMemories turns a design's memories into macros using FakeRAM2.0's asap7 backend (tools/FakeRAM2.0/orfs_asap7). Using it on real designs has turned up the problems below. Some of them bazel-orfs carries as stop-gap patches on ORFS until there's an upstream fix; those are linked. The rest are only reported here.

We have the information we need. What's left is to make some decisions and add some domain knowledge, then ask an AI to make these PRs and review them.

This came out of an AI-assisted review, so expect the odd mistake. The items marked confirmed were checked by generating macros from master with run.py --orfs_asap7_backend.

Geometry

1. Macro height floor and pin tracks. A 3.5 µm minimum height with no recorded origin, and shallow memories with many pins fail with "not enough tracks". Addressed in FakeRAM2.0: size the macro height from its pins, not a 3.5 um floor #4608. The design question there is still open: how far to take integer track arithmetic.
2. The snap grid is probably FreePDK45's. snap_width_nm: 190 and snap_height_nm: 1400 match nangate45's placement site (0.19 × 1.4 µm). asap7's site is 0.054 × 0.270.
3. The snap moves sides that are already on the grid. Because snap_side_to_grid rounds floats up, 32.2 µm (23 × 1.4) becomes 33.6, and 64.4 becomes 65.8. Confirmed by computing it; I haven't checked whether a real memory triggers it.
4. Hardcoded column mux factor of 1. Deep memories come out absurdly tall: 1024×32 is 4.18 × 331.8 µm (confirmed), and 8192×32 is 4.18 × 2654 µm. Stop-gap: 0067.
5. No minimum width. A macro narrower than the power-strap pitch can land between straps and fail PDN (PDN-0233). Stop-gap: 0088.

Pins

6. Pin names don't match the module. The macro always uses FakeRAM's own names (rd_out, addr_in, …), not the blackboxed module's (e.g. firtool's RW0_*), so the netlist can't link to it. There are no write masks either. Stop-gap: 0073. Its pin-height part is superseded by FakeRAM2.0: size the macro height from its pins, not a 3.5 um floor #4608.

Timing

7. ASAP7_TIMING_CONFIG is silently ignored (confirmed). Its keys (cycle_time, access_time, setup_time, …) don't match what TimingData reads (cycle_time_ns, access_time_ns, t_setup_ns, …). The generated .lib carries the built-in defaults (setup 0.050 ns, clock-to-output 0.218 ns, min_period 0.157 ns), not the config's 0.1, 0.5 and 1.0.
8. The timing doesn't depend on the memory (confirmed). 128×32 and 1024×32 get the same clock-to-output (0.218 ns) and min_period (0.157 ns), and access time is longer than the cycle time. _pre_layout.lib is byte-identical to .lib.

Robustness and tests

9. A missing shape silently becomes 128×32 (confirmed). A memory with no bits or rows gets m.get("bits", 32) / m.get("rows", 128): the run exits 0 and emits a 4.18 × 42.0 µm macro, not an error.
10. FakeRAM's tests don't run in CI. Neither the GitHub workflows nor Jenkins run tools/FakeRAM2.0/test. Run under a single pytest process, 6 of them fail, because factory_base_test.py leaves a mock registered in the global factory. All pass one file per process, which is how test_all.sh runs them.
11. Bazel can't stage the vendored tool. There's no filegroup for tools/FakeRAM2.0. Stop-gap: 0063.

Suggested Solution

Single-concern PRs, smallest first. Items 7 (deleting the dead config, so nothing changes), 9 and 10 change no output and are independent. Next comes 3, then the carried patches in order: 4, then 5, then 6.

Beyond that, a longer-term direction for discussion, not a proposal to do now:

• Take the geometry from the platform (tech LEF, the flow's track grid and the placement site), with integer DBU arithmetic, instead of a per-PDK Python dict.
• Keep only the parts that are fake by design (bitcell area and timing) as configuration.

Additional Context

All I wanted was some memories for asap7 so I could look at other aspects of the design. The stop-gap links point at a fixed bazel-orfs commit, so they stay valid after the patches retire.