Rounding up an array's addrmap elements' size to a power of 2

[megsx]

Let's say I don't know the exact size of an addrmap because it's configurable. And I want an array of it. Obviously I want the array stride to be a power of 2 for sane indexing. How do I do that?

For example:

addrmap foo_t #(longint unsigned A, longint unsigned B) {
   reg { field {} test; } treg[A];
   reg { field {} test; } vreg[B];
   // ... and more complicated contents ...
};

foo_t  foo[16];

The addressing = fullalign directive rounds up sizes of addrmap children, not of array elements.
Maybe I can wrap foo_t in bar_t, but it adds an undesirable extra indirection, and I don't think it actually works (only affects addresses not sizes):

addrmap bar_t #(longint unsigned A, longint unsigned B) {
   addressing = fullalign;
   foo_t foo(A, B);
}
bar_t  foo[16];

If there were a sizeof() operator, perhaps one could do foo_t foo[16] += ... some really complicated expression with sizeof(foo_t) repeated many times.... Not seeing that either, and no way I see to hide a complicated expression in a function.

Proper array indexing on specific address bits seems like something everyone wants, there must be an easy way to do this?

[amykyta3]

I cant think of a good way to accomplish this automatically. The SystemRDL standard does not define much in the way of introspection such as sizeof() operators.

In the past I have "solved" this by hardcoding a fixed power of 2 value for the block's stride, and relying on the compiler to throw an error if the stride is too small. Obviously this is not automatic.
Your best chance may be to calculate the stride based on the same parameters that augment the addrmap, but that will require some clever arithmetic since SystemRDL does not have a proper $clog2 operator.

[megsx]

Ah, `define is possible, that might help, thanks.
Agreed on looking forward to the next spec. SystemRDL is used not only to generate hardware, also for software to describe hardware that was not generated by SystemRDL and thus doesn't abide by its constraints. Some standard ways to optionally relax constraints when not generating hardware will be immensely useful. I'm happy to shed more light on this if the opportunity arises.