5.17.2 References in event source fields
Event sources must follow these rules when referring to fields or to resources.
Identifying resources and memory spaces
Event sources that refer to a resource or to a memory space should use the numeric resource id,
MemorySpaceInfo.spaceId, not the resource name string. If resource names are reported, which is discouraged, they must be consistent with the
Syntax of references in the format string
A format string can refer to values in this and other instances, with the following syntax and semantics. In the following list, variables are enclosed by angle brackets,
<…>, and optional items are enclosed by square brackets,
[…]. This list is ordered roughly from more common to less common references:
- Refers to a field in this event source. The client must make sure the field
- Refers to a resource in this instance. Only well-defined for synchronous
event sources, otherwise the results are undefined.
- Refers to a field in another, previous, event. The client must make sure the other event and field are enabled and must buffer the values of these fields. The semantics are only well-defined for event sources with a defined ordering relationship. Because event sources can only refer to past events, not future events, usually only the last event in a causal event chain can refer to all fields of that event chain. Clients are not expected to wait until data is available. Using this reference requires detailed knowledge of the ordering of the event sources involved.
- Refers to a resource in another instance. This is only well-defined for synchronous events where other instances are stable and are causally connected to this instance. For example an event source from a downstream cache might be able to refer to resources in its parent cache or parent core if they are causally connected. In some cases, an approximation of otherwise hard to produce data might still be useful, for example acquiring the approximate PC value of an otherwise unrelated sibling core to debug multithreading problems. Using this reference requires detailed knowledge of the causal relationship between instances and their events.
- Refers to an event field in a previous event of another
instance. The client must make sure the event and field are enabled in the
other instance and the client must buffer the values of these fields. This
is only well-defined if the events involved have a strict ordering
relationship and if the instances involved are strongly causally connected.
This might be the case, for example, when transactions flow through multiple
components of a memory subsystem. Using this reference requires very
detailed knowledge about the causal relationship between instances and their
- This is always relative to the instance that contains the
format string. The semantics are similar to C++ namespace scoping semantics.
It starts at the path of the instance that contains the format string, tries
instance_path, and if that fails,
repeatedly goes one level up, until it is found. This enables references to
children, siblings, and parent instances without needing to specify absolute
paths. The special token "
PARENT" can be
used as an explicit inverse scope to reach parents without specifying the
parent's name. It can be specified multiple times, but only at the beginning
of the path.