[oharboe]

A ROM, an inferred memory with no write port, is no longer counted against SYNTH_MEMORY_MAX_BITS.

The limit is the AUTO_MEMORIES policy's tripwire. A read/write memory larger than it belongs in a macro (AUTO_MEMORIES, fakeram) or a mock, and must not go undetected into flip-flops. A ROM holds constants that synthesis maps to logic like any other logic, and it goes through the normal flow. Counting ROMs meant that admitting a large one raised the limit for read/write memories of that size as well.

The coralnpu work in progress (#4653) needs this. coralnpu's FPU divider has an SRT bound table, a 128 x 83 ROM (10,624 bits), over the default of 4,096. On its own it synthesises on asap7 in about 3 s to about 700 cells (71 µm²). Random-content ROMs up to 128 kbit synthesise in about a minute, so ROMs, which are rare, get no limit of their own.

• mem_dump.py still lists every memory, a ROM marked as one, and stops on a read/write memory over the limit as before.
• variables.yaml says under SYNTH_MEMORY_MAX_BITS that ROMs are not counted, and why; variables.json and FlowVariables.md are regenerated.
• flow/test/test_mem_dump.py checks that a read/write memory over the limit stops synthesis, that a ROM of the same size does not, and that a read/write memory under the limit passes. Against the current mem_dump.py, the ROM case fails.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the memory limit checks to exclude ROMs (inferred memories with no write ports) from the SYNTH_MEMORY_MAX_BITS constraint. It updates the documentation, modifies mem_dump.py to identify ROMs and bypass the limit check, and adds corresponding unit tests. The review feedback suggests making the ROM detection logic in mem_dump.py more robust by safely handling potential KeyError, ValueError, or TypeError exceptions when parsing the WR_PORTS parameter.