Interpretation of total array size & implicit address allocation

[Alex Mykyta]

 Richard,

One ambiguity I have found in the spec was how to interpret the total byte-size of components instantiated as arrays. This is not something the RDL spec explicitly defines, so it is left up to the reader to interpret. This has implications on how automatic address allocation operates, and it seems that some commercial tools have made differing interpretations on this.

This came up in a discussion posted here if you want more context: https://github.com/SystemRDL/systemrdl-compiler/issues/169

For example:

addrmap myMap {
  reg { 
    field {
      sw = rw;
      hw = r;
    } f1;
  } reg1[2] += 0x100;
  reg {
    field {
      sw = rw;
      hw = r;
    } f2;
  } reg2;
};

What would reg2's address be inferred as? Apparently some tools would assume tight packing and allocate it to 0x104. Other tools, including my own, borrow the address overlap semantics of IP-XACT's SCR 7.18 clause which would interpret that as an address collision, and allocate this to 0x200 as the "next available" address. Since it seems there are differing interpretations on this, which is the correct one?

[Richard Weber]

Hello Alex,

I have no choice but to agree with the next address of 0x200, since I advocated for IP-XACT-2022 SCR 7.18 wording. Since SystemRDL is all about hardware/software interface, we need to make sure that the resulting C header files are valid and self-consistent. This was the guiding principle in the IP-XACT committee decision. Stride would be most likely implemented with a struct array in a C header file. The C header file would work well with 0x200, but, 0x104 would be a problem.  I would vote for clarification in the next version of the standard.

[Alex Mykyta]

Thank you for the clarification.