Model Information

This page provides detailed information about the OVP Fast Processor Model of the ARM armv8mpcore (AArch64) core.
This page is information about the armv8mpcore alias of the AArch64 variant.
Processor IP owner is ARM Holdings.

OVP Fast Processor Model is written in C.
Provides a C API for use in C based platforms.
Provides a native C++ interface for use in SystemC TLM2 platforms.

The model is written using the OVP VMI API that provides a Virtual Machine Interface that defines the behavior of the processor.
The VMI API makes a clear line between model and simulator allowing very good optimization and world class high speed performance.

The model is provided as a binary shared object and is also available as source (different models have different licensing conditions). This allows the download and use of the model binary or the use of the source to explore and modify the model.

The model has been run through an extensive QA and regression testing process.

Parallel Simulation using Imperas QuantumLeap
Traditionally, processor models and simulators make use of one thread on the host PC. Imperas have developed a technology, called QuantumLeap, that makes use of the many host cores found in modern PC/workstations to achieve industry leading simulation performance. To find out about the Imperas parallel simulation lookup Imperas QuantumLeap. There are videos of QuantumLeap on ARM here, and MIPS here. For press information related to QuantumLeap for ARM click here or for MIPS click here.
Many of the OVP Fast Processor Models have been qualified to work with QuantumLeap - this is indicated for this model below.

Embedded Software Development tools
This model executes instructions of the target architecture and provides an interface for debug access. An interface to GDB is provided and this allows the connection of many industry standard debuggers that use the GDB/RSP interface. For more information watch the OVP video here.
The model also works with the Imperas Multicore Debugger and advanced Verification, Analysis and Profiling tools.

Instruction Set Simulator (ISS) for ARM armv8mpcore (AArch64)
An ISS is a software development tool that takes in instructions for a target processor and executes them. The heart of an ISS is the model of the processor. Imperas has developed a range of ISS products for use in embedded software development that utilize this fast Fast Processor Model. The Imperas ARM armv8mpcore (AArch64) ISS runs on Windows/Linux x86 systems and takes a cross compiled elf file of your program and allows very fast execution. The ARM armv8mpcore (AArch64) ISS also provides access to standard GDB/RSP debuggers and connects to the Eclipse IDE and Imperas debuggers.

Overview of ARM armv8mpcore (AArch64) Fast Processor Model
Model Variant name: armv8mpcore (AArch64)
    ARM Processor Model
    Usage of binary model under license governing simulator usage.
    Note that for models of ARM CPUs the license includes the following terms:
    Licensee is granted a non-exclusive, worldwide, non-transferable, revocable licence to:
    If no source is being provided to the Licensee: use and copy only (no modifications rights are granted) the model for the sole purpose of designing, developing, analyzing, debugging, testing, verifying, validating and optimizing software which: (a) (i) is for ARM based systems; and (ii) does not incorporate the ARM Models or any part thereof; and (b) such ARM Models may not be used to emulate an ARM based system to run application software in a production or live environment.
    If source code is being provided to the Licensee: use, copy and modify the model for the sole purpose of designing, developing, analyzing, debugging, testing, verifying, validating and optimizing software which: (a) (i) is for ARM based systems; and (ii) does not incorporate the ARM Models or any part thereof; and (b) such ARM Models may not be used to emulate an ARM based system to run application software in a production or live environment.
    In the case of any Licensee who is either or both an academic or educational institution the purposes shall be limited to internal use.
    Except to the extent that such activity is permitted by applicable law, Licensee shall not reverse engineer, decompile, or disassemble this model. If this model was provided to Licensee in Europe, Licensee shall not reverse engineer, decompile or disassemble the Model for the purposes of error correction.
    The License agreement does not entitle Licensee to manufacture in silicon any product based on this model.
    The License agreement does not entitle Licensee to use this model for evaluating the validity of any ARM patent.
    Source of model available under separate Imperas Software License Agreement.
    Instruction pipelines are not modeled in any way. All instructions are assumed to complete immediately. This means that instruction barrier instructions (e.g. ISB, CP15ISB) are treated as NOPs, with the exception of any undefined instruction behavior, which is modeled. The model does not implement speculative fetch behavior. The branch cache is not modeled.
    Caches and write buffers are not modeled in any way. All loads, fetches and stores complete immediately and in order, and are fully synchronous (as if the memory was of Strongly Ordered or Device-nGnRnE type). Data barrier instructions (e.g. DSB, CP15DSB) are treated as NOPs, with the exception of any undefined instruction behavior, which is modeled. Cache manipulation instructions are implemented as NOPs, with the exception of any undefined instruction behavior, which is modeled.
    Real-world timing effects are not modeled: all instructions are assumed to complete in a single cycle.
    Performance Monitors are implemented as a register interface only except for the cycle counter, which is implemented assuming one instruction per cycle.
    TLBs are architecturally-accurate but not device accurate. This means that all TLB maintenance and address translation operations are fully implemented but the cache is larger than in the real device.
    Debug registers are implemented but non-functional (which is sufficient to allow operating systems such as Linux to boot). Debug state is not implemented.
    Models have been extensively tested by Imperas. ARM Cortex-A models have been successfully used by customers to simulate SMP Linux, Ubuntu Desktop, VxWorks and ThreadX on Xilinx Zynq virtual platforms.
Core Features:
    AArch64 is implemented at EL3, EL2, EL1 and EL0.
    The following ARMv8.2 core features are implemented: ARMv8.2-FP16, SVE
Memory System:
    Security extensions are implemented (also known as TrustZone). To make non-secure accesses visible externally, override ID_AA64MMFR0_EL1.PARange to specify the required physical bus size (32, 36, 40, 42, 44, 48 or 52 bits) and connect the processor to a bus one bit wider (33, 37, 41, 43, 45, 49 or 53 bits, respectively). The extra most-significant bit is the NS bit, indicating a non-secure access. If non-secure accesses are not required to be made visible externally, connect the processor to a bus of exactly the size implied by ID_AA64MMFR0_EL1.PARange.
    VMSA EL1, EL2 and EL3 stage 1 address translation is implemented. VMSA stage 2 address translation is implemented.
    LPA (large physical address extension) is implemented as standard in ARMv8.
    TLB behavior is controlled by parameter ASIDCacheSize. If this parameter is 0, then an unlimited number of TLB entries will be maintained concurrently. If this parameter is non-zero, then only TLB entries for up to ASIDCacheSize different ASIDs will be maintained concurrently initially; as new ASIDs are used, TLB entries for less-recently used ASIDs are deleted, which improves model performance in some cases (especially when 16-bit ASIDs are in use). If the model detects that the TLB entry cache is too small (entry ejections are very frequent), it will increase the cache size automatically. In this variant, ASIDCacheSize is 8
Advanced SIMD and Floating-Point Features:
    SIMD and VFP instructions are implemented.
    The model implements trapped exceptions if FPTrap is set to 1 in MVFR0 (for AArch32) or MVFR0_EL1 (for AArch64). When floating point exception traps are taken, cumulative exception flags are not updated (in other words, cumulative flag state is always the same as prior to instruction execution, even for SIMD instructions). When multiple enabled exceptions are raised by a single floating point operation, the exception reported is the one in least-significant bit position in FPSCR (for AArch32) or FPCR (for AArch64). When multiple enabled exceptions are raised by different SIMD element computations, the exception reported is selected from the lowest-index-number SIMD operation. Contact Imperas if requirements for exception reporting differ from these.
    Trapped exceptions are implemented in this variant (FPTrap=1)
SVE Features:
    SVE is implemented, with 512 bit vectors. The exact set of supported vector widths can be specified using parameter "SVEImplementedSizes". This parameter is a mask in which vector size Nx128 is supported if bit 1<<(N-1) is set in the mask. For example, a mask value of 0xf indicates that 128, 256, 384 and 512 bit vector widths are supported. As a second example, a value of 0x8b indicates that 128, 256, 512 and 1024 bit vector widths are supported. In this variant, "SVEImplementedSizes" is 0xf.
    For SVE First-fault and Non-fault vector loads, the UNKNOWN value returned for faulting loads (or those disabled by the FFR) can be specified using parameter "SVEFaultUnknown". In this variant, "SVEFaultUnknown" is 0xdfdfdfdfdfdfdfdf.
    When operating with a vector length less than the maximum length, the value of inaccessible vector and predicate elements is preserved.
Generic Timer:
    Generic Timer is present. Use parameter "override_timerScaleFactor" to specify the counter rate as a fraction of the processor MIPS rate (e.g. 10 implies Generic Timer counters increment once every 10 processor instructions).
Debug Mask:
    It is possible to enable model debug features in various categories. This can be done statically using the "override_debugMask" parameter, or dynamically using the "debugflags" command. Enabled debug features are specified using a bitmask value, as follows:
    Value 0x004: enable debugging of MMU/MPU mappings.
    Value 0x080: enable debugging of all system register accesses.
    Value 0x100: enable debugging of all traps of system register accesses.
    Value 0x200: enable verbose debugging of other miscellaneous behavior (for example, the reason why a particular instruction is undefined).
    Value 0x400: enable debugging of Performance Monitor timers
    Value 0x800: enable dynamic validation of TLB entries against in-memory page table contents (finds some classes of error where page table entries are updated without a subsequent flush of affected TLB entries).
    All other bits in the debug bitmask are reserved and must not be set to non-zero values.
Integration Support:
    This model implements a number of non-architectural pseudo-registers and other features to facilitate integration.
Memory Transaction Query:
    Two registers are intended for use within memory callback functions to provide additional information about the current memory access. Register transactPL indicates the processor execution level of the current access (0-3). Note that for load/store translate instructions (e.g. LDRT, STRT) the reported execution level will be 0, indicating an EL0 access. Register transactAT indicates the type of memory access: 0 for a normal read or write; and 1 for a physical access resulting from a page table walk.
Page Table Walk Query:
    A banked set of registers provides information about the most recently completed page table walk. There are up to six banks of registers: bank 0 is for stage 1 walks, bank 1 is for stage 2 walks, and banks 2-5 are for stage 2 walks initiated by stage 1 level 0-3 entry lookups, respectively. Banks 1-5 are present only for processors with virtualization extensions. The currently active bank can be set using register PTWBankSelect. Register PTWBankValid is a bitmask indicating which banks contain valid data: for example, the value 0xb indicates that banks 0, 1 and 3 contain valid data.
    Within each bank, there are registers that record addresses and values read during that page table walk. Register PTWBase records the table base address, register PTWInput contains the input address that starts a walk, register PTWOutput contains the result address and register PTWPgSize contains the page size (PTWOutput and PTWPgSize are valid only if the page table walk completes). Registers PTWAddressL0-PTWAddressL3 record the addresses of level 0 to level 3 entries read, respectively. Register PTWAddressValid is a bitmask indicating which address registers contain valid data: bits 0-3 indicate PTWAddressL0-PTWAddressL3, respectively, bit 4 indicates PTWBase, bit 5 indicates PTWInput, bit 6 indicates both PTWOutput and PTWPgSize. For example, the value 0x73 indicates that PTWBase, PTWInput, PTWOutput, PTWPgSize and PTWAddressL0-L1 are valid but PTWAddressL2-L3 are not. Register PTWAddressNS is a bitmask indicating whether an address is in non-secure memory: bits 0-3 indicate PTWAddressL0-PTWAddressL3, respectively, bit 4 indicates PTWBase, bit 6 indicates PTWOutput (PTWInput is a VA and thus has no secure/non-secure info). Registers PTWValueL0-PTWValueL3 contain page table entry values read at level 0 to level 3. Register PTWValueValid is a bitmask indicating which value registers contain valid data: bits 0-3 indicate PTWValueL0-PTWValueL3, respectively.
Artifact Page Table Walks:
    Registers are also available to enable a simulation environment to initiate an artifact page table walk (for example, to determine the ultimate PA corresponding to a given VA). Register PTWI_EL1S initiates a secure EL1 table walk for a fetch. Register PTWD_EL1S initiates a secure EL1 table walk for a load or store (note that current ARM processors have unified TLBs, so these registers are synonymous). Registers PTW[ID]_EL1NS initiate walks for non-secure EL1 accesses. Registers PTW[ID]_EL2 initiate EL2 walks. Registers PTW[ID]_S2 initiate stage 2 walks. Registers PTW[ID]_EL3 initiate AArch64 EL3 walks. Finally, registers PTW[ID]_current initiate current-mode walks (useful in a memory callback context). Each walk fills the query registers described above.
MMU and Page Table Walk Events:
    Two events are available that allow a simulation environment to be notified on MMU and page table walk actions. Event mmuEnable triggers when any MMU is enabled or disabled. Event pageTableWalk triggers on completion of any page table walk (including artifact walks).
Artifact Address Translations:
    A simulation environment can trigger an artifact address translation operation by writing to the architectural address translation registers (e.g. ATS1CPR). The results of such translations are written to an integration support register artifactPAR, instead of the architectural PAR register. This means that such artifact writes will not perturb architectural state.
TLB Invalidation:
    A simulation environment can cause TLB state for one or more address translation regimes in the processor to be flushed by writing to the artifact register ResetTLBs. The argument is a bitmask value, in which non-zero bits select the TLBs to be flushed, as follows:
    Bit 0: EL0/EL1 stage 1 secure TLB
    Bit 1: EL0/EL1 stage 1 non-secure TLB
    Bit 2: EL2 stage 1 TLB
    Bit 3: EL0/EL1 non-secure stage 2 TLB
    Bit 4: EL3 stage 1 TLB
Halt Reason Introspection:
    An artifact register HaltReason can be read to determine the reason or reasons that a processor is halted. This register is a bitfield, with the following encoding: bit 0 indicates the processor has executed a wait-for-event (WFE) instruction; bit 1 indicates the processor has executed a wait-for-interrupt (WFI) instruction; and bit 2 indicates the processor is held in reset.
System Register Access Monitor:
    If parameter "enableSystemMonitorBus" is True, an artifact 32-bit bus "SystemMonitor" is enabled for each PE. Every system register read or write by that PE is then visible as a read or write on this artifact bus, and can therefore be monitored using callbacks installed in the client environment (use opBusReadMonitorAdd/opBusWriteMonitorAdd or icmAddBusReadCallback/icmAddBusWriteCallback, depending on the client API). The format of the address on the bus is as follows:
    bits 31:26 - zero
    bit 25 - 1 if AArch64 access, 0 if AArch32 access
    bit 24 - 1 if non-secure access, 0 if secure access
    bits 23:20 - CRm value
    bits 19:16 - CRn value
    bits 15:12 - op2 value
    bits 11:8 - op1 value
    bits 7:4 - op0 value (AArch64) or coprocessor number (AArch32)
    bits 3:0 - zero
    As an example, to view non-secure writes to writes to CNTFRQ_EL0 in AArch64 state, install a write monitor on address range 0x020e0330:0x020e0333.
System Register Implementation:
    If parameter "enableSystemBus" is True, an artifact 32-bit bus "System" is enabled for each PE. Slave callbacks installed on this bus can be used to implement modified system register behavior (use opBusSlaveNew or icmMapExternalMemory, depending on the client API). The format of the address on the bus is the same as for the system monitor bus, described above.

Model downloadable (needs registration and to be logged in) in package arm.model for Windows32 and for Linux32. Note that the Model is also available for 64 bit hosts as part of the commercial products from Imperas.
OVP simulator downloadable (needs registration and to be logged in) in package OVPsim for Windows32 and for Linux32. Note that the simulator is also available for 64 bit hosts as part of the commercial products from Imperas.
OVP Download page here.
OVP documentation that provides overview information on processor models is available OVP_Guide_To_Using_Processor_Models.pdf.

Full model specific documentation on the variant armv8mpcore (AArch64) is available OVP_Model_Specific_Information_arm_AArch64.pdf.

Location: The Fast Processor Model source and object file is found in the installation VLNV tree:
Processor Endian-ness: This model can be set to either endian-ness (normally by a pin, or the ELF code).
Processor ELF Code: The ELF code for this model is: 0xb7
QuantumLeap Support: The processor model is qualified to run in a QuantumLeap enabled simulator.

TLM Initiator Ports (Bus Ports)
Port TypeNameWidth (bits)Description
SystemC Signal Ports (Net Ports)
Port TypeNameDescription

No FIFO Ports in armv8mpcore.

Execution Modes
More Detailed Information

The armv8mpcore OVP Fast Processor Model also has parameters, model commands, and many registers.
The model may also have hierarchy or be multicore and have other attributes and capabilities.
To see this information, please have a look at the model variant specific documents.
Click here to see the detailed document OVP_Model_Specific_Information_arm_AArch64.pdf.

Other Sites/Pages with similar information

Information on the armv8mpcore OVP Fast Processor Model can also be found on other web sites:: has the library pages has more information on the model library

A couple of documents (from other related sites that might be of interest) VMI Run Time (VMI RT) API Reference Guide iGen Model Generator Introduction

Two Videos on these models (from other sites) riscvOVPsim. A complete RISC-V ISS for bare-metal software development and Specification Compliance Test Development riscvOVPsim. A complete RISC-V ISS for bare-metal software development and Specification Compliance Test Development

Currently available Fast Processor Model Families.

FamilyModel Variant
MIPS Models    MIPS Models aliases ISA M14K M14KcTLB M14KcFMM 4KEc 4KEm 4KEp M4K 4Kc 4Km 4Kp 24Kc 24Kf 24KEc 24KEf 34Kc 34Kf 34Kn 74Kc 74Kf 1004Kc 1004Kf 1074Kc 1074Kf microAptivC microAptivP microAptivCF interAptiv interAptivUP proAptiv 5Kf 5Kc 5KEf 5KEc M5100 M5150 M6200 M6250 MIPS32R6 P5600 P6600 I6400 MIPS64R6 I6500 (aliases)
ARM Models    ARM Models aliases ARMv4T ARMv4xM ARMv4 ARMv4TxM ARMv5xM ARMv5 ARMv5TxM ARMv5T ARMv5TExP ARMv5TE ARMv5TEJ ARMv6 ARMv6K ARMv6T2 ARMv6KZ ARMv7 ARM7TDMI ARM7EJ-S ARM720T ARM920T ARM922T ARM926EJ-S ARM940T ARM946E ARM966E ARM968E-S ARM1020E ARM1022E ARM1026EJ-S ARM1136J-S ARM1156T2-S ARM1176JZ-S Cortex-R4 Cortex-R4F Cortex-A5UP Cortex-A5MPx1 Cortex-A5MPx2 Cortex-A5MPx3 Cortex-A5MPx4 Cortex-A8 Cortex-A9UP Cortex-A9MPx1 Cortex-A9MPx2 Cortex-A9MPx3 Cortex-A9MPx4 Cortex-A7UP Cortex-A7MPx1 Cortex-A7MPx2 Cortex-A7MPx3 Cortex-A7MPx4 Cortex-A15UP Cortex-A15MPx1 Cortex-A15MPx2 Cortex-A15MPx3 Cortex-A15MPx4 Cortex-A17MPx1 Cortex-A17MPx2 Cortex-A17MPx3 Cortex-A17MPx4 AArch32 AArch64 Cortex-A32MPx1 Cortex-A32MPx2 Cortex-A32MPx3 Cortex-A32MPx4 Cortex-A35MPx1 Cortex-A35MPx2 Cortex-A35MPx3 Cortex-A35MPx4 Cortex-A53MPx1 Cortex-A53MPx2 Cortex-A53MPx3 Cortex-A53MPx4 Cortex-A55MPx1 Cortex-A55MPx2 Cortex-A55MPx3 Cortex-A55MPx4 Cortex-A57MPx1 Cortex-A57MPx2 Cortex-A57MPx3 Cortex-A57MPx4 Cortex-A72MPx1 Cortex-A72MPx2 Cortex-A72MPx3 Cortex-A72MPx4 Cortex-A73MPx1 Cortex-A73MPx2 Cortex-A73MPx3 Cortex-A73MPx4 Cortex-A75MPx1 Cortex-A75MPx2 Cortex-A75MPx3 Cortex-A75MPx4 MultiCluster ARMv6-M ARMv7-M Cortex-M0 Cortex-M0plus Cortex-M1 Cortex-M3 Cortex-M4 Cortex-M4F (aliases)
POWER Models    POWER Models aliases mpc82x UISA m476 m470 m460 m440 (aliases)
Renesas Models    Renesas Models aliases V850 V850E1 V850E1F V850ES V850E2 V850E2M V850E2R RH850G3M m16c r8c RL78-S1 RL78-S2 RL78-S3 (aliases)
RISC-V Models    RISC-V Models aliases RV32I RV32IM RV32IMC RV32IMAC RV32G RV32GC RV32GCN RV32E RV32EC RV64I RV64IM RV64IMC RV64IMAC RV64G RV64GC RV64GCN (aliases)
Other Models    Other Models aliases Synopsys ARC_600 Synopsys ARC_605 Synopsys ARC_700 Synopsys ARC_0x21 Synopsys ARC_0x22 Synopsys ARC_0x31 Synopsys ARC_0x32 openCores_generic Andes_N25 Andes_NX25 Microsemi_CoreRISCV Microsemi_MiV_RV32IMA SiFive_E31 SiFive_E51 SiFive_U54 Xilinx MicroBlaze_V7_00 Xilinx MicroBlaze_V7_10 Xilinx MicroBlaze_V7_20 Xilinx MicroBlaze_V7_30 Xilinx MicroBlaze_V8_00 Xilinx MicroBlaze_V8_10 Xilinx MicroBlaze_V8_20 Xilinx MicroBlaze_V9_50 Xilinx MicroBlaze_V10_00 Xilinx MicroBlaze_ISA Altera Nios II_Nios_II_F Altera Nios II_Nios_II_S Altera Nios II_Nios_II_E (aliases)