[oharboe]

Wires up one more experimental AUTO_MEMORIES feature: mask_lane_width on a .memories override entry (ADDITIONAL_MEMORIES). It sets the bits per write-mask lane, with the last lane holding the rest, so a RAM whose byte enables cover a word that is not whole bytes can become a macro. The case that needs it is pulp's tc_sram as cva6's I-cache tag RAM: 25 bits, with 4 byte enables of 8, 8, 8 and 1 bit (asap7/cva6 in #4777).

No current design is asked to change anything. AUTO_MEMORIES is experimental and asap7-only, and no design sets mask_lane_width. Without the field, behaviour is as before:

• Lanes split the word evenly, and FakeRAM's Verilog model writes the same loop with the same LANE_WIDTH.
• An uneven split is refused as before. It is now refused in the schema, naming the memory, instead of later in FakeRAM.

With the field:

• lanes * width >= bits > (lanes - 1) * width; anything else is refused, as is a width without lanes.
• FakeRAM builds the mask bus as before, one pin per lane, and its Verilog model writes each lane's own bit range.
• docs/user/AutoMemories.md documents it next to the other overrides.

Smoke test it needs: asap7/tinyRocket, the one design with AUTO_MEMORIES = 1, builds as before, and the existing memories and FakeRAM tests pass.

New tests: flow/scripts/memories/schema_test.py covers the check and the field surviving merge and dump. tools/FakeRAM2.0/test/spsram_mask_test.py covers the config, the model's lanes and the even split. gen_memories_test's 512 × 17 fixture now has one write-enable bit and one data bit per bit, as yosys writes it; the earlier fixture only passed because the uneven split went unchecked.

Integration: The-OpenROAD-Project/bazel-orfs#1484 carries this and builds asap7/cva6 to global route with the tag RAM as a macro.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces support for ragged write mask lanes (where the last lane can be narrower than the others) in memory configurations and Verilog generation. It adds a mask_lane_width parameter to the schema, updates validation logic, and modifies the Verilog exporter to handle uneven splits. The review feedback suggests three key improvements: validating even splits in validate_emittable when mask_lane_width is zero, robustly handling potential null values in JSON parsing to prevent TypeError, and clarifying the error message in memory_config.py when mask_lane_width is provided without mask_lanes.

[openroad-ci]

🔍 QoR check

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

Commit 5e68479 · Jenkins build #5 · Baseline: build · View build on dashboard

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

[maliberty]

1. The mask_lanes field and the mask pin's width are never compared, and the doc example falls into that gap.

   • The schema check (lane_width_check) tests mem.mask_lanes.
   • FakeRAM takes its lane count from the mask pin's width instead (single_port_pins in tools/FakeRAM2.0/orfs_asap7/generate.py).
   • merge keeps the detected pins unless the override brings its own.
   • So the doc's example, { "name": "tag_ram", "mask_lanes": 4, "mask_lane_width": 8 } applied to a detected memory, passes the schema. FakeRAM then sees a detected per-bit mask pin, or none at all for a yosys W0_* memory (lanes=0). It fails with an error that doesn't point at the real cause, such as "mask_lane_width without mask_lanes" when the user did set mask_lanes.
   • asap7/cva6: the RAMs as upstream has them, made macros #4777 avoids this only because its tag RAM entry spells out all its pins, with be 4 bits wide.

   Suggested fix: in validate_emittable, require each mask pin's width to equal mask_lanes, naming the memory. Also either change the doc example to show the full entry with pins, or say that an override of a detected memory must bring a matching mask pin.

2. The new uneven-split refusal can't break existing flows. validate_emittable runs only on converted memories (gen_memories.py:64). For yosys-detected memories, mask_lanes = len(WR_EN)//wr_ports comes out as bits, so the split is always even. Firtool masks divide evenly too. The old 512×17 test fixture had 4 enable bits over 17 data bits and only passed because nothing checked it; the fix to the fixture is right.

• In validate_emittable, the guard if mem.mask_lanes or mem.mask_lane_width: is redundant, because lane_width_check already returns when both are zero.

[oharboe]

Thanks, all three check out against the code.

1. Agreed. FakeRAM counts lanes from the mask pin's width and never reads mask_lanes, and merge keeps the detected pins, so the bare override in the doc passed the schema and failed later in FakeRAM. d70413d makes validate_emittable refuse, naming the memory, a mask pin whose width is not mask_lanes, and also mask_lanes on a memory with no mask pin at all, which is the doc example applied to a detected memory with no mask. Detected memories already agree (yosys's <port>_mask is mask_lanes wide, firtool takes mask_lanes from its pin), and so do the four entries in asap7/cva6: the RAMs as upstream has them, made macros #4777's cva6.memories. 59a9a4d makes the doc example a whole entry with its pins, and says that an override changing mask_lanes must bring its pins with a matching mask pin.
2. Agreed, no change: only converted memories reach validate_emittable, and yosys's and firtool's masks split evenly.
3. Agreed, the guard is gone in d70413d.

Tested: schema_test (the new test fails without the check), gen_memories_test, detect_test, idiomatic_test, spsram_mask_test, black 26.10.1; and asap7/cva6 synthesis with AUTO_MEMORIES plus the RAM LEC tests through bazel-orfs with the change applied.