IPXACT description of "indirect" registers

[Milan Olin]

Hello,

I've been looking for some example on how the indirect registers shall/can be described in IPXACT memoryMaps but I'm failing to find any.

Borrowing the definition of "indirect registers" e.g. from DVCON doc below

https://dvcon-proceedings.org/wp-content/uploads/uvm-register-modelling-at-the-integration-level-testbench.pdf
"indirect” shows that “internal” address space is accessed via a data/index register pair located in
“top” address space. All registers located in “internal” address space are indirect registers

I'm wondering :

• how the indirect address space shall be described in IPXACT.  e.g.  dedicated memoryMap or addressBlock or so ?
• how the link between indirect address space and data/index pair of registers shall be captured there, if possible at all ...

Any idea/hint appreciated

--Milan

[kock]

Hello Milan,

Indirect registers are described in Section 6.8 of the IEEE 1685-2022 standard:

6.8 Indirect interfaces
The contents of an indirectly accessible memory map are not accessible at a fixed address via a bus interface. A bus interface accesses an indirectly accessible memory map via reads and writes to fields the bus interface can directly access.

indirectAddressRef (mandatory) references the register field used for addressing the indirectly accessible memory map. The referenced field is usually directly accessible via a bus interface. This reference is made using a fieldReferenceGroup (see C.13).

indirectDataRef (mandatory) references the register field used for read/write access for the indirectly accessible memory map. The field is usually accessible via a standard bus interface. This reference is made using a fieldReferenceGroup (see C.13).

An indirectInterface element contains either a memoryMapRef element or one or more transparentBridge elements.

1. memoryMapRef (type: Name) references a name of a memory map defined in the containing description. This memory map is indirectly accessible.
2. transparentBridge is an unbounded list of references to initiator interfaces. If the interface is of a bus definition that is addressable, a transparentBridge element may be included. A transparent bridge is one in which all addressing entering the target interface exits the above referenced initiator interface without any modifications.
   • The initiatorRef (mandatory; type: Name) attribute shall reference an initiator interface (see 6.7.5) in the containing description.
   • vendorExtensions (optional) holds any vendor-specific data from other namespaces that is applicable to this bus interface. See C.27.

Here is an example taken from the IEE 1685-2022 standard:

<!-- LINK: indirectInterface: see 6.8, Indirect interfaces -->
<ipxact:indirectInterfaces>
  <ipxact:indirectInterface>
    <ipxact:name>IndirectMemoryInterface</ipxact:name>
    <ipxact:indirectAddressRef>
      <ipxact:memoryMapRef memoryMapRef="SimpleMapWithBlock"/>
      <ipxact:addressBlockRef addressBlockRef="SimpleAddressBlock"/>
      <ipxact:registerRef registerRef="IAR"/>
      <ipxact:fieldRef fieldRef="IAR"/>
    </ipxact:indirectAddressRef>
    <ipxact:indirectDataRef>
      <ipxact:memoryMapRef memoryMapRef="SimpleMapWithBlock"/>
      <ipxact:addressBlockRef addressBlockRef="SimpleAddressBlock"/>
      <ipxact:registerRef registerRef="IDR"/>
      <ipxact:fieldRef fieldRef="IDR"/>
    </ipxact:indirectDataRef>
    <ipxact:memoryMapRef>MapForMemory</ipxact:memoryMapRef>
  </ipxact:indirectInterface>
</ipxact:indirectInterfaces>

This example assume there is a memoryMap named simpleMapWithBlock that contains the indirect registers that contain address and data. This memoryMap shall be referenced by a target interface. The transaction on the target interface will then be forwarded to memoryMap MapForMemory using the address and data obtained through the referenced address and data registers.

In the 1685-2014 the mechanism is slightly different. The indirect address and data fields are referenced through IDs there rather than by names.

I hope this helps,
Erwin