How to interpret modeRefs for port fieldMaps

[Jason H]

The fieldMaps are a great addition in the 1685-2022 release. However, the language about fieldMap modeRef elements is somewhat unclear.

A use case which seems to be supported is specifying multiple fieldMap elements to cover less straightforward mappings to fields, leveraging the fieldSlice indices and range, as well as the partSelect, to map the bits. As a simple example, if I have a "logic [63:0]", e.g. port with 64-bit vector, that I want to map to two 32-bit fields within an array of two registers, it seems like I can do that with two fieldMaps on the port. Effectively:
 

myPort[31:0]  -> blk.reg[0].fld
myPort[63:32] -> blk.reg[1].fld

This can be done with two fieldMap elements on the port.

My confusion comes when you then consider modeRefs. In other places where modeRefs are used, such as fieldAccessPolicies, there can only be one active fieldAccessPolicy. However, the wording is different.

For fieldAccessPolicy:

Quote

modeRef (optional) identifies the operating mode for which the fieldAccessPolicy element is active by referencing a mode name in the containing description and providing a priority. An fieldAccessPolicy is active if it references an active mode and that has highest priority among the active modes referenced in all fieldAccessPolicy elements of the fieldAccessPolicies element. The modeRef element value shall be unique within the containing fieldAccessPolicies element. The modeRef element has an attribute priority (mandatory; type nonNegativeInteger) which indicates the priority of the referenced mode for this fieldAccessPolicy. The lower the value, the higher the priority. The priority value of a modeRef element shall be unique in the scope of the referenced modes inside the fieldAccessPolicies element. If no modeRef element is present, then the fieldAccessPolicy element applies to all modes.

For fieldMaps:

Quote

 

modeRef (optional) references a mode of the encapsulating component in which this fieldMap is active. If no modeRef is present, then the fieldMap is always active. A fieldMap is active if it references an active mode and it has highest priority among the active modes referenced in all fieldMap elements of the fieldMaps element. The modeRef element value shall be unique within the containing fieldMap element. The modeRef element has an attribute priority (mandatory; type nonNegativeInteger) which indicates the priority of the referenced mode for this fieldMap. The lower the value, the higher the priority. The priority value of a modeRef element shall be unique in the scope of the referenced modes inside the fieldMap element.

 

In the fieldMap case, the uniqueness of the modeRef value as well as its priority are stated relative to a single fieldMap, whereas the fieldAccessPolicy uniqueness is required across all fieldAccessPolicy elements within the parent fieldAccessPolicies element. There is also no uniqueness constraint in the schema for modeRef priority on fieldMap elements.
 

TL;DR
Based on the above, my interpretation is that you can have multiple active fieldMap elements, and when there is a mode-dependence, you can have multiple fieldMap elements referencing the same mode at the same priority. Is this the correct interpretation?
 

[kock]

Hi Jason,

Yes, your interpretation is correct. The unique priorities in elements other than fieldMap are needed for the access resolution for register field bits (Annex C.3). This is not required for fieldMap since it does not contribute to that resolution. A fieldMap only describes "connectivity" between register fields and port slices. This "connectivity" can be mode specific. 

Best regards,
Erwin