[prim_ram_1p] Ram tiling for sram_ctrl and prim_ram_1p

[Razer6]

No description provided.

[Razer6]

That seems to be a bug in the generator.

[Razer6]

Fixed in #25665

[a-will]

This makes for interesting questions for prims in general:

• Are we able to concisely describe all the properties needed to instantiate specific primitives that might fan out from the simple generic prim abstraction?
  • This particular PR has a parameter for tiling arrays of a provided depth to reach the full depth of the generic prim.
  • Another PR seeks to specify the tile instance widths.
  • Would another user possibly want to have instance-level control of aspect ratios (which map to different primitives from the tech lib / memory compiler)?
• If yes, then we can carry on adding these one-by-one.
• If no, does it make sense to provide a top-specific, prim library-specific package that carries the configurations that can be looked up?
  • For instance level control, we could have a single ID parameter that can be exposed at the top level, and that could be used by prim libraries to define arbitrary configuration functions, which are defined for specific tops and consumed in the prim library modules.

I'm not sure which route is going to be better, but it might be worth thinking about and discussing.

[Razer6]

This is a good question. One reason for this parameter to be an instance level rather than a global package was in general to implement tiling one level higher even. I do not see a reason why tiling should be implemented in the tech prim rather than in the generic primitive. This would make backdoor loading much easier as it supports tiling as a first class citizen, e.g., when there is no tiling, there is only one loop iteration of the tiling loop.

[andreaskurth]

Thx @Razer6 and @a-will for proposing this change and raising relevant questions. Also looping in @matutem -- it would be great to get your perspective also on DV aspects.

Other questions that come to my mind:

• This PR propagates the new InstDepth parameter to the prim_ram_1p_scr instance in sram_ctrl, but what about other instances, also of prim_ram_1p_adv (e.g., in usbdev or in i2c)?
• How do we deal with DFT I/Os, which may depend on the tiling? Do we generally pass 2D arrays (for 2D tiling) of arrays/structs of signals through the design to all (possibly) tiled instances? Or should a prim library package define a generic DFT struct that integrators can override according to their needs?

[Razer6]

• This PR propagates the new InstDepth parameter to the prim_ram_1p_scr instance in sram_ctrl, but what about other instances, also of prim_ram_1p_adv (e.g., in usbdev or in i2c)?

That's totally doable, though I wanted to start with sram_ctrl's memory first, as tiling might be used there first (bigger memory).

• How do we deal with DFT I/Os, which may depend on the tiling? Do we generally pass 2D arrays (for 2D tiling) of arrays/structs of signals through the design to all (possibly) tiled instances? Or should a prim library package define a generic DFT struct that integrators can override according to their needs?

In general, I am raising the question of whether 2D tiling should be implemented in prim_ram_1p_adv. That way, the backdoor loading could be much more constant across different integrators. In general, I am a fan of passing arrays rather than a common type, which would need to be the common denominator supporting all possible tiling configs of the system, which leaves a lot of unused signals...

[Razer6]

I think the tiling information must be propagated via the parameter information as its dimensions are instance-dependent. Different instances have different dimensions, yielding different wide DFT signals. This cannot be determined at instance level via a a function.

[matutem]

Why using this parameter if it can be derived from others? Seems redundant.

[Razer6]

Technically no need for that. Unfortunately, the topgen tooling cannot yet deal with the computed number of RAM instances. I'll file an issue on that, for a later improvement.

[matutem]

Could this just be a localparam in the individual module holding the RAMs?

[Razer6]

Unfortunately no. This parameter is used as a dimension for the DFT signals, which depends on the number of RAM instances.

[matutem]

I think @a-will comment about other configs is regarding FPGA tiling? Also @Razer6 case is similar to the foundry concerns. In any case I think both cases are important and orthogonal, as they suggest tiling along rows or columns. As for the DV concerns, they probably mostly concern mem_bkdr_util, scrambling, and the such. My understanding is that those utils need to access individual arrays, so we may need to create multiple arrays in mem_bkdr per high level RAM using the configuration; that way the interface exposed by mem_bkdr for each high-level memory would be simpler.

I assume row tiling will use tile 0 for the lowest addresses. Column tiling has to decide on endian-ness... fun :)

The FPGA flows don't use mem_bkdr_util, and we currently splice the memory contents into the bitstream, yet I assume we need to scramble and generate ECC for them. Also, perhaps backdoor RAM access is possible for other FPGA vendors?

Can we try to zoom into config in terms of rows and columns and then tackle mem_bkdr in one shot. WDYT?

[a-will]

I think @a-will comment about other configs is regarding FPGA tiling? Also @Razer6 case is similar to the foundry concerns. In any case I think both cases are important and orthogonal, as they suggest tiling along rows or columns.

We have aligned here. We would seek to model tiling with parameters along both dimensions. This affects the number of RAM macro instances, which affects the size of the tech lib-specific ports in the port list. Thus, we need the parameter to flow from the top level, so it's available to the entire hierarchy for those ports. 🙂

I assume row tiling will use tile 0 for the lowest addresses. Column tiling has to decide on endian-ness... fun :)

No, no endianness ambiguity, please. The bit indices and the macro instance indices must always grow in the same direction. Endianness only affects how an image represented as a sequence of bytes gets laid out, and that is an orthogonal issue to tiling.

The FPGA flows don't use mem_bkdr_util, and we currently splice the memory contents into the bitstream, yet I assume we need to scramble and generate ECC for them. Also, perhaps backdoor RAM access is possible for other FPGA vendors?

Backdoor access is generally only available if you build the logic yourself, hehe. At run time, that can get complicated, but it's interesting.

For splicing specifically, yes, ECC and scrambling and such must be accommodated in the image construction. We have the utilities for this for flash_ctrl already, it turns out.

[andreaskurth]

CHANGE AUTHORIZED: hw/ip/otbn/rtl/otbn.sv
CHANGE AUTHORIZED: hw/ip/prim/rtl/prim_ram_1p_adv.sv
CHANGE AUTHORIZED: hw/ip/prim/rtl/prim_ram_1p_scr.sv
CHANGE AUTHORIZED: hw/ip/prim_generic/rtl/prim_generic_ram_1p.sv
CHANGE AUTHORIZED: hw/ip/sram_ctrl/data/sram_ctrl.hjson
CHANGE AUTHORIZED: hw/ip/sram_ctrl/rtl/sram_ctrl.sv
CHANGE AUTHORIZED: hw/top_earlgrey/data/top_earlgrey.hjson
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/chip_earlgrey_asic.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

This PR adds depth tiling parameters for prim_ram_1p. No functional change, and for Earlgrey the instances remain effectively untiled.