Why does XLS expose RAM interfaces but not emit internal RAM modules for proc state arrays?

[ForBloodB]

Hi XLS folks,

I’m trying to understand the intended memory-lowering direction in XLS codegen.

From the docs, it looks like XLS has support for RAMs through proc/channel-style RAM interfaces and --ram_configurations. That makes sense when the memory is an external block connected to the generated design.

But I’m curious about another case: large fixed-size arrays that live inside proc state.

For example, conceptually a proc may carry a fixed-size state array:

state_array: u32[512]

and use it with a fairly RAM-like access pattern: one indexed read, one single-element update, and an explicit cycle boundary before the read value is consumed.

In this case, is there a design reason XLS prefers to keep this as ordinary proc state instead of lowering it to an internal synchronous RAM module?

I’m especially interested in the distinction between:

1. exposing an external RAM interface, and
2. emitting a generic internal RAM module for eligible proc state arrays.

I’m not thinking about instantiating vendor primitives like Xilinx RAMB18/XPM directly. More like a generic behavioral module such as a 1R1W synchronous RAM, which FPGA tools could infer as BRAM and ASIC flows could potentially replace with an SRAM macro.

A few specific questions:

• Is internal proc-state RAM lowering considered out of scope for XLS codegen?
• Is the current RAM interface approach preferred because it keeps memories outside the generated block?
• Would an opt-in pass for fixed-size proc state arrays be aligned with XLS’s direction, if it is conservative about synchronous read semantics?
• Where would this kind of feature best live: IR lowering, proc-to-block conversion, or Verilog codegen?

I’m asking because I’ve been experimenting with proc-style kernels where large state arrays are functionally memory-like, but the generated RTL can become very FF/LUT-heavy on FPGA unless the memory boundary is made explicit.

Thanks! I’d love to understand the intended design philosophy before trying to propose anything.