Jump to content

Interpretation of total array size & implicit address allocation

Recommended Posts


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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...