The FPSID characteristics are:
Provides top-level information about the floating-point implementation.
This register largely duplicates information held in the MIDR. ARM deprecates use of it.
This register is part of:
There is one instance of this register that is used in both Secure and Non-secure states.
Implemented only if the implementation includes the Advanced SIMD and floating-point functionality.
FPSID is a 32-bit register.
The FPSID bit assignments are:
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Implementer | SW | Subarchitecture | PartNum | Variant | Revision |
Implementer codes are the same as those used for the MIDR.
For an implementation by ARM this field is 0x41, the ASCII code for A.
Software bit. Defined values are:
SW | Meaning |
---|---|
0 |
The implementation provides a hardware implementation of the floating-point instructions. |
1 |
The implementation supports only software emulation of the floating-point instructions. |
In ARMv8-A the only permitted value is 0.
Subarchitecture version number. For an implementation by ARM, defined values are:
Subarchitecture | Meaning |
---|---|
0000000 |
VFPv1 architecture with an IMPLEMENTATION DEFINED subarchitecture. |
0000001 |
VFPv2 architecture with Common VFP subarchitecture v1. |
0000010 |
VFPv3 architecture, or later, with Common VFP subarchitecture v2. The VFP architecture version is indicated by the MVFR0 and MVFR1 registers. |
0000011 |
VFPv3 architecture, or later, with Null subarchitecture. The entire floating-point implementation is in hardware, and no software support code is required. The VFP architecture version is indicated by the MVFR0 and MVFR1 registers. This value can be used only by an implementation that does not support the trap enable bits in the FPSCR. |
0000100 |
VFPv3 architecture, or later, with Common VFP subarchitecture v3, and support for trap enable bits in FPSCR. The VFP architecture version is indicated by the MVFR0 and MVFR1 registers. |
For a subarchitecture designed by ARM the most significant bit of this field, register bit[22], is 0. Values with a most significant bit of 0 that are not listed here are reserved.
When the subarchitecture designer is not ARM, the most significant bit of this field, register bit[22], must be 1. Each implementer must maintain its own list of subarchitectures it has designed, starting at subarchitecture version number 0x40.
In ARMv8-A the permitted values are 0000011 and 0000100.
An IMPLEMENTATION DEFINED part number for the floating-point implementation, assigned by the implementer.
An IMPLEMENTATION DEFINED variant number. Typically, this field distinguishes between different production variants of a single product.
An IMPLEMENTATION DEFINED revision number for the floating-point implementation.
This register can be read using VMRS with the following syntax:
VMRS <Rt>, <spec_reg>
This register can be written using VMSR with the following syntax:
VMSR <spec_reg>, <Rt>
This syntax uses the following encoding in the System instruction encoding space:
<spec_reg> | reg |
---|---|
FPSID | 0000 |
The register is accessible as follows:
Control | Accessibility | |||||
---|---|---|---|---|---|---|
E2H | TGE | NS | EL0 | EL1 | EL2 | EL3 |
x | x | 0 | - | RW | n/a | RW |
x | 0 | 1 | - | RW | RW | RW |
x | 1 | 1 | - | n/a | RW | RW |
This table applies to all instructions that can access this register.
When access to this register is permitted, write accesses are ignored.
For a description of the prioritization of any generated exceptions, see section G1.11.2 (Exception priority order) in the ARM® Architecture Reference Manual, ARMv8, for ARMv8-A architecture profile for exceptions taken to AArch32 state, and section D1.13.2 (Synchronous exception prioritization) for exceptions taken to AArch64 state. Subject to the prioritization rules, the following traps and enables are applicable when accessing this register.
When HCR_EL2.E2H==0 :
If CPACR.cp10==00, accesses to this register from PL1 are UNDEFINED.
When EL2 is implemented and is using AArch64 and SCR_EL3.NS==1 && HCR_EL2.E2H==0 :
If CPTR_EL2.TFP==1, Non-secure accesses to this register from EL1 are trapped to EL2.
If HCR_EL2.TID0==1, Non-secure read accesses to this register from EL1 are trapped to EL2.
When EL2 is implemented and is using AArch64 and SCR_EL3.NS==1 && HCR_EL2.E2H==1 && HCR_EL2.TGE==0 :
If CPTR_EL2.FPEN==00, Non-secure accesses to this register from EL1 are trapped to EL2.
If CPTR_EL2.FPEN==10, Non-secure accesses to this register from EL1 are trapped to EL2.
If HCR_EL2.TID0==1, Non-secure read accesses to this register from EL1 are trapped to EL2.
When EL2 is implemented and is using AArch32 and SCR_EL3.NS==1 :
If HCPTR.TCP10==1, Non-secure accesses to this register from EL1 are trapped to Hyp mode.
If HCPTR.TCP10==1, Non-secure accesses to this register from EL2 are UNDEFINED.
If HCR.TID0==1, Non-secure read accesses to this register from EL1 are trapped to Hyp mode.
When EL3 is implemented and is using AArch32 and SCR_EL3.NS==1 :
If NSACR.cp10==0, Non-secure accesses to this register from EL1 and EL2 are UNDEFINED.
When EL3 is implemented and is using AArch64 :
If CPTR_EL3.TFP==1, accesses to this register from EL1 and EL2 are trapped to EL3.
28/09/2017 08:24
Copyright © 2010-2017 ARM Limited or its affiliates. All rights reserved. This document is Non-Confidential.