Add an RFC for arbitrary Memory shapes.

[zyp]

Rendered

[stafverhaegen-chipflow]

Would it also be made possible to specify granularity of the WritePort with arbitrary shape ?

[whitequark]

Would it also be made possible to specify granularity of the WritePort with arbitrary shape ?

I think this should be possible iff the shape is an ArrayLayout.

[zyp]

Since we're talking about granularity for write enables and not width conversions, there's not really any need to enforce a uniform element shape, and I'm not sure it's worthwhile to try enforcing that the granularity aligns with natural subdivisions of a shape-castable either. We'd end up with a bunch of special casing for lib.data that's not necessarily even correct.

Consider something like a StructLayout({'a': 1, 'b': 7, 'c': 8, 'd': 16}). Depending on the application, it could make perfect sense to use this with granularity=8 even though some fields are packed together and some fields spans a multiple.

[whitequark]

I feel that it's important to not blindly allow a case that results in arbitrarily torn writes. I would say that if you want granularity to be less than the full word, it has to be a Shape and not a shape-castable then. We can always relax this later, but not the other way around, and I think a conservative choice is wise here.

I agree that a dependency on lib.data would be gratuitous here.

[whitequark]

We have discussed this RFC on the 2024-01-22 weekly meeting. The disposition was to merge with the following changes

• Memory.width is kept and becomes a read-only wrapper for Shape.cast(self.shape).width;
• Memory.depth becomes read-only.

There was consensus that allowing granularity to be specified for lib.data.ArrayLayout shapes is desirable, but as Memory currently lives in hdl and not lib this is not possible at the moment.

@zyp Could you please create a tracking issue for this RFC and insert that and the starting date in the RFC text?