# System Register XML
for Future Architecture Technologies
(2019-04)

# April 2019

## 1. Introduction

This is the 2019-04 release of the System Register XML for Future Architecture Technologies. It describes registers for the Arm A-profile architecture plus the following Future Architecture Technologies:

- Scalable Vector Extension, SVE2.
- Transactional Memory Extension, TME.
- Embedded Trace Extension, ETE.
- Trace Buffer Extension, TRBE.

The Proprietary Notice gives details of the terms and conditions under which this package is provided.

If you have comments on the content of this package, please send them by e-mail to support@arm.com. Give:

- The title, "System Register XML for Future Architecture Technologies".
- The version, "2019-04".
- A concise explanation of your comments.

Please see the Documentation for more information on the general structure of these descriptions.

## 2. Contents

This Version | 2019-04 | [HTML] | [PDF] | [XML]
Change Markups | Future 2019-04 from V8.5 BET10 | [HTML] | [PDF] |

## 3. Release notes

### Change history

This is the first public release of Future Architecture Technologies and hence there are no listed changes.

### Known issues

- The following information is not present for PMSEVFR_EL1.E[16].
  Transactional. If TME is not implemented, this bit is RAZ/WI.
  The possible values of this bit are:

  E[16] | Meaning
  --- | ---
  0 | Transactional event is ignored.
  | 1 | Do not record samples that have the Transactional event == 0.

  This bit is ignored by the PE when PMSFCR_EL1.FE == 0.
  This bit resets to an architecturally UNKNOWN value on a reset
- The following information is not present for PMCCFILTR_EL0.T[23].
  Non-transactional state filtering bit. Controls counting in Non-transactional state. If TME is not implemented, this bit is RES0.
  The possible values of this bit are:

  T[23] | Meaning
  --- | ---
  0 | This bit has no effect on filtering of cycles.
  | 1 | Do not count cycles in Non-transactional state.

  This bit resets to an architecturally UNKNOWN value on a reset.
- For register TRBSR_EL1, the following bits must be preserved on a warm reset:
  EC, bit [31:25]
  IRQ, bit [22]
  TRG, bit [21]
  WRAP, bit [20]
  S, bit [17]
  MSS, bit [15:0]
  This is not explicitly stated in the current XML.
- Links in the XML documentation to ESR_ELx will not work. These should be to ESR_EL1, ESR_EL2 or ESR_EL3 registers depending on the location.

## 4. Documentation

### General

A description within the XML contains the following sections:

Purpose
  A short description of the purpose of the register in the Architecture.
Configuration
  How the register is architecturally mapped onto another System register or a memory-mapped register. If the configuration of the PE affects the implementation of the register, then information about this is also included here. This section also summarizes the behavior of the register on a reset.
Attributes
  The size of the register. For registers where the layouts of the fields differ based on configuration, or other state within the PE, this section also summarizes the different layouts.
Field descriptions
  The register diagram, and a description of the behavior of each field within the register.

### Memory-mapped registers

A memory-mapped register description also contains the following sections:

Accessing the ...
  The address or offset of the register in the memory map, and the accessibility.

### System registers

A System register description also contains an "Accessing the ..." section, that includes:

- The assembler syntax for the instructions used to access the register, and how the instruction is encoded.
- Pseudocode that describes the execution of all instructions used to access the register, including information about traps and enables that apply upon that access.
- For some System registers, additional text is provided which gives extra information regarding the access to the register.
- The accessibility pseudocode for a register assumes that that register is implemented and that all features which affects its accesses are implemented. In most cases, the behaviour upon access to a register is determined in part or in whole by the Exception Level at which it is accessed, and so the pseudocode is structured around this assumption.