Content for OVP Fast Processor Model Variant: ARM / ARMv5

VIDEOS
Multi Processor Debug of a platform including an Andes RISC-V N25 running FreeRTOS and ARM Cortex-A15MPx4 running SMP Linux
ARM Extendable Platform Kits and Tools Demo Video
Using the ARM DS-5 Debugger with Imperas simulators and models demonstration video
Continuous Integration and Test Automation with Jenkins
Sketch Cartoon Introduction to Imperas
ARM TrustZone Video Application Note
Simulating Andes RISC-V N25 running FreeRTOS and ARM Cortex-A15MPx4 running SMP Linux
ARM Bare Metal Demos Video Presentation
ARM Video Presentation of Booting uClinux/Linux
Video Presentation of SystemC TLM2.0 ARM Integrator Platform booting Linux
64 Bit and Multiple Quad Core Processors Video Demonstration
QuantumLeap Parallel Simulation using multi-core host PC gaining significant simulation speed.
Hetero 1xARM7 3xMIPS32LE Demonstration Video
Application Development and Debug using GDB / Eclipse Demonstration Video
RISC-V Custom Instruction Design and Verification Flow
Altera Nios II Bare Metal & Cyclone III Linux Booting Demo Video
Using the Green Hills Software MULTI Debugger with Imperas simulators and models demonstration video
on this link.

">DVCon 2021. A personal perspective on the history of SystemVerilog and Superlog

Imperas CEO Simon Davidmann Introducing Imperas Software
Information on Imperas at ARM TechCon 2016
DVCon 2021. 25 years after Verisity, verification is still evolving
Customer case study for AUDI Nira with the Imperas Solution of Software Testing in Automotive
(more videos)
DOWNLOAD REFERENCE/DEMO PLATFORMS
IntegratorCP booting Linux on Cortex-A9UP
SystemC TLM2.0 IntegratorCP with Cortex-A9UP
Self contained ARM Cortex-A examples
TLM2.0 executable demos for ARM Cortex-A
Platform including ARM Cortex-A9MPx4 to run ARM MPCore Sample Code
Versatile Express booting Linux on Cortex-A9MP Single, Dual and Quad Core
Self contained ARM examples for ARM Classic, Cortex-A, Cortex-M and Cortex-R profile processors
Versatile Express booting Linux on Cortex-A15MP Single, Dual and Quad Core
Versatile Express booting Linux kernels on four Cortex-A15MP Quad Core processors
Self contained ARM examples utilizing the ARM v8 architecture
Self contained ARM examples utilizing the ARM AArch64 ARMv8 architecture
TLM2.0 executable demos
Main OVP Download including OVPsim Simulator and Self Contained Examples of all CPU Models using The
Versatile Express booting Linux on Cortex-A9MP Single, Dual and Quad Core
Versatile Express booting Linux on Cortex-A15MP Single, Dual and Quad Core
IntegratorCP booting Linux on ARM926EJ-S or Cortex-A9UP
Platform including ARM Cortex-A9MPx4 to run ARM MPCore Sample Code
Versatile Express booting Linux kernels on four Cortex-A15MP Quad Core processors
TLM2.0 executable demos
Self contained ARM Cortex-R examples
Self contained ARM Cortex-M3 examples
TLM2.0 executable demos for ARM Cortex-M3
Self contained ARM Cortex-M examples
TLM2.0 executable demos for ARM Cortex-M
ARM Cortex-M3 running Micrium uC/OS-II
ARM Cortex-M3 running FreeRTOS
ARM Cortex-M3 running Micrium uC/OS-II
ARM Cortex-M3 running FreeRTOS
Platform using FMv1 memory map booting Linux kernels on Cortex-A57MP processor
Platform using FMv1 memory map booting Linux kernels on Cortex-A53MP and Cortex-A57MP processor
Self contained ARM examples
IntegratorCP booting Linux
SystemC TLM2.0 IntegratorCP
IntegratorCP booting Nucleus
AtmelAT91SAM7
IntegratorCP with examples using the eCos operating system
TLM2.0 Platform using FMv1 memory map booting Linux kernels on Cortex-A53MP processor
AtmelAT91SAM7
IntegratorCP booting Nucleus
IntegratorCP with examples using the eCos operating system
Platform using FMv1 memory map booting Linux kernels on Cortex-A57MP and Cortex-A53MP processor big.
ARM7 and MIPS32 hetero multicore

here.

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 ARMv5


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 ARMv5 ISS runs on Windows/Linux x86 systems and takes a cross compiled elf file of your program and allows very fast execution.
The ARM ARMv5 ISS also provides access to standard GDB/RSP debuggers and connects to the Eclipse IDE and
Imperas debuggers.

Overview of ARM ARMv5 Fast Processor Model


Model Variant name: ARMv5
Description:
    ARM Processor Model
Licensing:
    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.
Limitations:
    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.
Verification:
    Models have been extensively tested by Imperas.
Features:
    The precise set of implemented features in the model is defined by ID registers. Use overrides to modify these if required (for example override_PFR0 or override_AA64PFR0_EL1).
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 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).
    All other bits in the debug bitmask are reserved and must not be set to non-zero values.
AArch32 Unpredictable Behavior:
    Many AArch32 instruction behaviors are described in the ARM ARM as CONSTRAINED UNPREDICTABLE. This section describes how such situations are handled by this model.
Equal Target Registers:
    Some instructions allow the specification of two target registers (for example, double-width SMULL, or some VMOV variants), and such instructions are CONSTRAINED UNPREDICTABLE if the same target register is specified in both positions. In this model, such instructions are treated as UNDEFINED.
Floating Point Load/Store Multiple Lists:
    Instructions that load or store a list of floating point registers (e.g. VSTM, VLDM, VPUSH, VPOP) are CONSTRAINED UNPREDICTABLE if either the uppermost register in the specified range is greater than 32 or (for 64-bit registers) if more than 16 registers are specified. In this model, such instructions are treated as UNDEFINED.
Floating Point VLD[2-4]/VST[2-4] Range Overflow:
    Instructions that load or store a fixed number of floating point registers (e.g. VST2, VLD2) are CONSTRAINED UNPREDICTABLE if the upper register bound exceeds the number of implemented floating point registers. In this model, these instructions load and store using modulo 32 indexing (consistent with AArch64 instructions with similar behavior).
If-Then (IT) Block Constraints:
    Where the behavior of an instruction in an if-then (IT) block is described as CONSTRAINED UNPREDICTABLE, this model treats that instruction as UNDEFINED.
Use of R13:
    In architecture variants before ARMv8, use of R13 was described as CONSTRAINED UNPREDICTABLE in many circumstances. From ARMv8, most of these situations are no longer considered unpredictable. This model allows R13 to be used like any other GPR, consistent with the ARMv8 specification.
Use of R15:
    Use of R15 is described as CONSTRAINED UNPREDICTABLE in many circumstances. This model allows such use to be configured using the parameter "unpredictableR15" as follows:
    Value "undefined": any reference to R15 in such a situation is treated as UNDEFINED;
    Value "nop": any reference to R15 in such a situation causes the instruction to be treated as a NOP;
    Value "raz_wi": any reference to R15 in such a situation causes the instruction to be treated as a RAZ/WI (that is, R15 is read as zero and write-ignored);
    Value "execute": any reference to R15 in such a situation is executed using the current value of R15 on read, and writes to R15 are allowed (but are not interworking).
    Value "assert": any reference to R15 in such a situation causes the simulation to halt with an assertion message (allowing any such unpredictable uses to be easily identified).
    In this variant, the default value of "unpredictableR15" is "execute".
Unpredictable Instructions in Some Modes:
    Some instructions are described as CONSTRAINED UNPREDICTABLE in some modes only (for example, MSR accessing SPSR is CONSTRAINED UNPREDICTABLE in User and System modes). This model allows such use to be configured using the parameter "unpredictableModal", which can have values "undefined" or "nop". See the previous section for more information about the meaning of these values.
    In this variant, the default value of "unpredictableModal" is "nop".
Integration Support:
    This model implements a number of non-architectural pseudo-registers and other features to facilitate integration.
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
OVP simulator downloadable (needs registration and to be logged in) in package OVPsim for Windows32 and for Linux32
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 ARMv5 is available OVP_Model_Specific_Information_arm_ARMv5.pdf.

Configuration


Location: The Fast Processor Model source and object file is found in the installation VLNV tree: arm.ovpworld.org/processor/arm/1.0
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: 0x28
QuantumLeap Support: The processor model is qualified to run in a QuantumLeap enabled simulator.

TLM Initiator Ports (Bus Ports)


Port Type Name Width (bits) Description
master INSTRUCTION 32
master DATA 32

SystemC Signal Ports (Net Ports)


Port Type Name Description
reset input
fiq input
irq input
sei input

No FIFO Ports in ARMv5.


Exceptions


Name Code Description
Reset 0
Undefined 1
SupervisorCall 2
PrefetchAbort 5
DataAbort 6
IRQ 8
FIQ 9

Execution Modes


Mode Code Description
User 16
FIQ 17
IRQ 18
Supervisor 19
Abort 23
Undefined 27
System 31

More Detailed Information

The ARMv5 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_ARMv5.pdf.

Other Sites/Pages with similar information

Information on the ARMv5 OVP Fast Processor Model can also be found on other web sites::
www.imperas.com has more information on the model library.