Release Notes for System Registers for Armv8.5-A 2019-06 (bet)

Change history

  • Array representation in encoding has changed to align with pseudocode representation. Previously the array index was displayed in array brackets. The new representation moves the array index to outside the brackets. For example:

    Previous representation New representation
    [n:2:0] n[2:0]
    0b01[n:2:0] 0b01:n[2:0]
  • The description of access to the read-only registers, ERXPFGF_EL1 and ERXFR_EL1, has been corrected.
  • The accessibility pseudocode for the following System instructions have been corrected: CFPRCTX, CPPRCTX, DC IGSW, DC IGDSW, DC IGVAC, DC IGDVAC, DVPRCTX.
  • The accessibility pseudocode for the following registers has been corrected:
    • AArch64: SP_EL0, VSTCR_EL0.
    • AArch32: All AMU registers.
  • Relaxation of the VOffset field description in the following registers:
    • AArch64: CNTHP_CVAL_EL2, CNTHPS_CVAL_EL2, CNTHV_CVAL_EL2, CNTHVS_CVAL_EL2, CNTP_CVAL_EL0, CNTPS_CVAL_EL1, CNTV_CVAL_EL0.
    • AArch32: CNTHP_CVAL, CNTHPS_CVAL, CNTHV_CVAL, CNTHVS_CVAL, CNTP_CVAL, CNTV_CVAL, CNTVOFF.
  • Relaxation of field values from RAZ/WI to RES0 in the following AMU registers:
    • AArch64: AMCR_EL0, AMUSERENR_EL0, AMCNTENCLR0_EL0, AMCNTENSET0_EL0, AMEVTYPER0<n>_EL0, AMCNTENCLR1_EL0, AMCNTENSET1_EL0, AMEVTYPER1<n>_EL0.
    • AArch32: AMCR, AMUSERENR, AMCNTENCLR0, AMCNTENSET0, AMEVTYPER0<n>, AMCNTENCLR1, AMCNTENSET1, AMEVTYPER1<n>.
  • Many simple clarifications and corrections are also present, but are too small to be listed here. These can be seen in the Change Markup PDF provided.

Known issues

  • The memory-mapped Generic Timer register descriptions have incorrect information, and so must not be relied upon. This will be corrected in a future release. The definitive source for these registers is the Arm Architecture Reference Manual Armv8, for Armv8-A architecture profile.
  • There are differences in the GIC registers in this XML package when compared to the GIC register descriptions in the Generic Interrupt Controller Architecture Specification document. The definitive source for these registers is the document, and there will be corrections to these registers in the next release.
  • The line starting "If no instruction has been sampled since the PE left Reset state, Debug state, or a state where PC Sample-based profiling is prohibited" in the EDPCSR and PMPCSR register descriptions is incorrect. This will be corrected in a future release to:
    • If no instruction has been retired since the PE left Reset state, Debug state, or a state where PC Sample-based profiling is prohibited, the sampled value is UNKNOWN.
    • If an instruction has been retired but this is the first time the *PCSR register is read since the PE left Reset state [and only Reset state], the sampled value is permitted but not required to be 0xFFFFFFFF.
  • The ESR_EL2.EC field descriptions for 0b100100, 0b100101, 0b110100 and 0b110101 need to be updated for the new usage in Armv8.4.
  • The first line of the HCR_EL2.TID4 field description, under "AArch64" is missing an indication that these register accesses are trapped on EL1 reads.
  • The definition of GCR_EL1.RRND references a non-existant register, RTSR_EL1. This register reference should be RGSR_EL1.
  • The HCR_EL2.EnSCXT is attributed to the ARMv8.0-CSV3 feature. This is in fact a field introduced by ARMv8.0-CSV2.

Potential upcoming changes

We are looking in improvements to the information that is provided in the XML. In some cases these changes may impact users. Here is a list of areas where we may make changes in a future release:

  • The instruction encoding tables currently present values as binary values, with the prefix "0b". We are considering whether these values are better represented in a syntax compatible with pseudocode.
  • Some registers in the Arm architecture are recursive, for example ESR_ELn. We are looking into how these can be better represented in the XML.
  • How the read/write behaviors in register fields are identified is being investigated.
  • The content within the <usage_constraint_text> and <access_mechanism_text> is being transferred into the <access_text> element. In a future release the <usage_constraint_text> and <access_mechanism_text> will be removed.