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.

[proppy]

#861 has some background on the current (and possible future direction considered at the time) for RAM support.

maybe @grebe can shed more light if what you're proposing (state RAM lowering) would be in scope?

another potentially related work stream is [Explicit State Access] by @NL02, maybe we could support some custom verilog module FFI similar to what we have for channel fifos?

[ForBloodB]

Thanks, this is very helpful. I’ll read through #861 more carefully and continue exploring how the existing RAM support direction relates to proc-state arrays.

[ericastor]

It might indeed be worth considering this as a way to reduce area; however, doing it automatically means adding more constraints to the schedule (since RAMs usually have request->response times >= 1 cycle) - and even blocking certain optimizations we could otherwise do by treating different elements of the array differently. This makes state->RAM lowering a more nuanced architectural decision!

I think in general we need to revisit how we want to support RAMs in XLS & DSLX, probably in a more native fashion than the RAM rewrite system. Making them usable for state storage might be a part of this bigger picture.

[ericastor]

... and I ended up pontificating more than I did answering the questions! Let's try that again. 😄

An opt-in feature for this would probably be a good thing, even before we reconsider how RAMs work entirely. From a user-facing perspective, I think we have two options:

1. An attribute in DSLX that the user puts on an array-typed state element. We can then handle this in one of two ways:

   1. During IR conversion, lower the state element to a RAM. This has the smallest "blast radius" in terms of changes required, but blocks the most optimizations, since we don't currently model RAM inputs & outputs as having their actual correlation during XLS optimization. Also, we'd need some sort of naming convention so the user can know what channels to expect to have to add to their RAM rewrites settings.
   2. Lower to a state element with some sort of XLS IR annotation. Right before RAM rewriting, we could check if a state element is all of: annotated, only accessed via array_index operations, and only written to by values created through single array_update operations. If all three conditions apply, we could then convert this state element to a RAM. The big problem here is the blast radius - we'd need to figure out how to use IR to direct later stages to instantiate a RAM, or at least be predictable enough that the user could know how to hook up their RAM.

2. A scheduling & codegen option that says "I want this proc's state element named 'X' to be lowered to a RAM using the following Verilog syntax." This makes things configurable externally, but at the cost of making things harder to understand locally... and it generally seems complicated.

... you can see why this gets messy quickly! But maybe there's something we can land to make this manageable without obstructing whatever we want to do eventually.

[ForBloodB]

Thanks for the insightful and patient explanation! I agree this probably needs to come from the actual functional structure, not just from a late backend hint.

The reason I’m interested in this is that, in my experiments, DSLX-generated Verilog on Xilinx FPGAs often ends up using LUTRAM or LUT/FF-heavy storage for array-like proc state, which consumes a lot of on-chip resources. This is especially surprising to me when the generated Verilog already looks close to a synchronous RAM access pattern.

I also do some digital ASIC design, so I can see why exposing RAM interfaces is a clean direction for IC flows, where SRAM MACORs are usually provided by the technology/library side. But for FPGA flows, I wonder if it may be useful to have an IR-level way to mark or infer selected state arrays as RAM-like storage, while staying compatible with the current external RAM interface / RAM rewrite structure, so codegen can emit something that downstream FPGA tools are more likely to map to BRAM.

Of course, I understand this is hard: it needs reasoning about access patterns, timing, memory size, and also what the FPGA synthesizer can actually infer.

Anyway, thanks again for the detailed explanation. I may try exploring whether there is a way to make memory inference work while staying compatible with the current XLS direction.