Release notes for System Registers for Future Architecture Technologies (2020-06)

Future Architecture Technologies change history

    No data changes have been made to system registers for this architecture version.

    Future Architecture Technologies known issues

      There are no known issues for this architecture version.

      Armv8.6 change history

      • Architectural feature names used in the XML have been altered to a new format. See List of new vs old names for a list of the old and new names.
      • The accessibility pseudocode for the following System instruction has been updated:
        • AArch64: TLBI RVAALE1.
      • The accessibility pseudocode for the following registers has been updated:
        • In addition, in accessibility pseudocode for AArch64 registers, conditions that check ELUsingAArch32(ELx) when ELx is higher than the current Exception level, have this redundant check on ELUsingAArch32(ELx) removed. Redundant accessibility text for EDSCR.SDD handling has also been removed.
      • The architecture has been relaxed to permit the upper 8 bits of the ASID to be written 0 by the software when the context being invalidated only uses 8 bits. This applies to all the AArch64 TLBI maintenance instructions.
      • Extension to ERRDEVAFF Affinity fields to enable subsets of PEs at an affinity level.
      • Clarification that in the ERRGSR register, a record can choose not to expose the Valid bit through ERRGSR .
      • The architecture has been relaxed so that the address in FAR_ELx on an exception due to a tag check fault caused by a DC ZVA instruction is IMPLEMENTATION DEFINED as one of:
        • FAR_ELx contains the lowest address that gave rise to the fault.
        • FAR_ELx contains the address specified in the register argument of the instruction, as generated by MMU faults caused by DC ZVA.
      • Clarification of the behaviour of DC GVA and DC GZVA instructions in the ESR_ELx.CM field on a Data Abort.
      • Corrected field descriptions in EDPRCR and EDPRSR for when ARMv8.3-DoPD (FEAT_DoPD) is implemented.
      • In PMBSR_EL1, introduced new EC value and MSS for a buffer management event for an IMPLEMENTATION DEFINED reason.
      • Clarification of the priority of the HFGITR_EL2.ERET == 1 trap over the HCR_EL2.API == 0 trap.
      • The HCR_EL2.ATA field description incorrectly stated that its behavior is dependent on SCR_EL3.ATA. This is corrected to be consistent with the accessibility pseudocode in the System registers and instructions dependent on this bit.
      • ID_AA64MMFR2_EL1.NV updated to indicate optionality of ARMv8.3-NV (FEAT_NV) and ARMv8.4-NV (FEAT_NV2).
      • The GCR_EL1.Exclude field description is missing information about when the Allocation Tag value 0 is used. This is now clarified.
      • Clarification of the interaction between HCR_EL2.FWB and SCTLR_EL1.C.
      • Clarification that conditions for access to ExPD bits in TCR_ELx registers refer to Unprivileged access, not EL0 accesses.
      • The PMSICR_EL1.ECOUNT field description incorrectly stated that this field is RES1 when PMSIDR_EL1.ERnd is 0. The statement is now removed.
      • Restriction that the RAS common fault injection mechanism handles only errors that are explicitly supported at the node.
      • Clarification of requirements for upper bits of VA Range for VBAR_ELx.
      • Correction to state that HCR_EL2.TLOR trap is Non-secure only.
      • Corrected list of System instructions unallocated when Armv8.5-MemTag (FEAT_MTE) is not implemented.
      • The description of the ID_AA64ISAR0_EL1.AES field has been corrected to state that the presence of the AES instructions without the 64-bit PMULL instructions (value 0b0001) is not permitted.
      • Updated content for PMEVTYPER<n>.{NSH,SH} / PMCCFILTR_EL0.SH in Secure-only implementation with EL2.
      • The NRDY field descriptions in the following regsiters have been modified to correctly represent the behavior:
      • The MAIR_EL<n>.Attr<n> = 0b11110000 description has been clarified to include a condition on ARMv8.5-MemTag (FEAT_MTE).
      • The HCR_EL2.NV1 description incorrectly depends on the value of HCR_EL2.NV2. This has been corrected to remove that dependency.
      • The Purpose section of RNDRRS incorrectly described that reseeding happens at an IMPLEMENTATION DEFINED rate. This is corrected to state that the reseeding happens before the read of the random number.
      • The Configuration statements for ERRCRICRx, ERRERICRx, ERRFHICRx and ERRIRQSR external registers in debug have been clarified to state when the registers are implemented.
      • EDPFR.AMU now supports ARMv8.6-AMU (FEAT_AMUv1p1).
      • Added statement that ROMADDR is UNKNOWN when Valid == 0b00 to MDRAR_EL1.ROMADDR and DBGDRAR.ROMADDR.
      • Correction to MPAMF_PRI_IDR.DSPRI_WD and INTPRI_WD fields to indicate the correct maximum width of the MPAMCFG_PRI.DSPRI and INTPRI fields.

      Armv8.6 known issues

      • The accessibility pseudocode of SCXTNUM_EL1 and the description of HCR_EL2.NV1 value 0b1 will be updated to add SCXTNUM_EL1 to the list of registers trapped to EL2..
      • Clarification of a number of MPAM registers.
        • The purpose in MPAMF_CCAP_IDR corrected to indicate that it provides information about the MPAMPCFG_CMAX.CMAX field.
        • The description of MPAMF_CSUMON_IDR.CSU_RO is corrected to indicate it applies to the MSMON_CSU monitor register.
        • The description of MPAMF_CSUMON_IDR.NUM_MON is corrected to indicate the number of instances implemented and the maximum valid value.
      • SCTLR_ELx.ITFSB field descriptions do not fully define exception entry synchronisation requirements for Tag Check Faults due to instructions executed before exception entry.
      • Corrections to the field value description in PMSCR_EL1.PCT, PMSCR_EL2.PCT, TRFCR_EL1.TS, TRFCR_EL2.TS, and TRFCR.TS to remove HCR_EL2.{E2H, TGE} is {1, 1} from the list of conditions when the Time stamp is 0, and for the TRFCR registers, add the conditions that EL3 is using AAArch32, or EL2 is enabled in the curent Security state and using AArch32.
      • Correction to the field descriptions in MDCR_EL3.STE and SPME fields to say that the fields have an Effective value of 1 if EL3 is not implemented and the Effective value of SCR_EL3.NS is 0.
      • The HCR_EL2.NV1 description incorrectly depends on the value of HCR_EL2.NV2. This will be corected to remove that dependency.
      • Correction to the RESS and VA fields descriptions of DBGBVR<n>_EL1 and DBGWVR<n>_EL1 to indicate conditions when the RESS field is ignored, and the valid IMPLEMENTATION DEFINED behavior when not ignored.
      • Clarification of the description in the Data Abort ISS of ESR_ELx.ISV when RAS is not implemented.

      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:

      • Introduce field_rangesets to better capture a single field that is split across noncontiguous bits (eg. DSPSR_EL0.IT is an 8-bit field using bits [15:10, 26, 25]).
        • Such fields effectively appear as multiple fields today, but this would enable these to be viewed as one. To preserve backwards compatibility, we propose to preserve this for at least 6 months. The additional entries would have an is_duplicate == TRUE property.
        • For the register diagrams represented via reg_fieldset, there may be multiple entries for the same split field. They would all point to the same is_duplicate == FALSE entry. A concept of a label would be introduced to capture the text that is displayed in each case.
      • Introduce a concept of field_array_indexes for field_array that allow field_array indices to be discontinuous. This would also make the index of the array and fieldset explicity. E.g HSTR_EL2.Tn, Bits [15, 13:5, 3:0] n = 15, 13:5, 3:0. This would not have a backward compatibility option.
      • We are looking at representation of reset information using an ASL expression in certain cases.
      • We are looking at separating accessors (instructions/external accesses) from registers. This is likely to impact "Index by Encoding", "External registers by offset" and may introduce separate pages for instructions/accessors vs. the registers. This may impact the schema and the presentation of the content.
      • Some changes to register names may be introduced and there may be changes to the number of registers or names. The instructions accessing registers would be unchanged - preserving the architecture intent.
      • Register accesses that always look like simple reads or writes will be extended to have some ASL expressions. Where register accesses cause additional side effects, ASL functions that describe these effects will be added. Currently these details are only expressed in text.
      • We are considering the obsoletion of some DTD elements based on usage and analysis.
      • 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.
      • The reset information in the 'Configuration' section of some register descriptions have incorrect information, and must not be relied upon. Please refer to the field descriptions for the correct reset information. The information in the 'Configuration' section will be removed in a future release.