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, ResourceInfo.rscId or MemorySpaceInfo.spaceId, not the resource name string. If resource names are reported, which is discouraged, they must be consistent with the ResourceInfo.name or MemorySpaceInfo.name field.

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:

%{<field_name>…}
Refers to a field in this event source. The client must make sure the field is enabled.
%{:resource.[<group_name>.]<resource_name>…}
Refers to a resource in this instance. Only well-defined for synchronous event sources, otherwise the results are undefined.
%{:event.<event_source_name>.<event_field>…}
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.
%{:instance.<instance_path>:resource.[<group_name>.]<resource_name>…}
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.
%{:instance.<instance_path>:event.<event_source_name>.<event_field>…}
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 events.
<instance_path>
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 to find 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.
Non-ConfidentialPDF file icon PDF version101196_0100_03_en
Copyright © 2018, 2019 Arm Limited or its affiliates. All rights reserved.