Content for OVP Fast Processor Model Variant: ARM / Cortex-A57MPx4

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
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
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
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 Cortex-A57MPx4


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

Overview of ARM Cortex-A57MPx4 Fast Processor Model


Model Variant name: Cortex-A57MPx4
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.
    ARMv8 architecture models additionally require a run time model license - contact Imperas for more information.
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.
    Performance Monitors are implemented as a register interface only.
    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.
    The optional SIMD Cryptographic Extension instructions are not supported.
Verification:
    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.
    AArch32 is implemented at EL3, EL2, EL1 and EL0.
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 or 48 bits) and connect the processor to a bus one bit wider (33, 37, 41, 43, 45 or 49 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.
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 not are implemented in this variant (FPTrap=0)
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).
Generic Interrupt Controller:
    GIC block is implemented (GICv2, including security extensions). Accesses to GIC registers can be viewed externally by connecting to the 32-bit GICRegisters bus port. Secure register accesses are at offset 0x0 on this bus; for example, a secure access to GIC register GICD_CTLR can be observed by monitoring address 0x00001000. Non-secure accesses are at offset 0x80000000 on this bus; for example, a non-secure access to GIC register GICD_CTLR can be observed by monitoring address 0x80001000
    The internal GIC block can be disabled by raising signal GICCDISABLE, in which case the GIC needs to be modeled using a platform component instead. Input signals vfiq_CPU and virq_CPU can be used by this component to raise virtual FIQ and IRQ interrupts on cores in the cluster if required.
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. Registers PTWAddressL0-PTWAddressL3 record the addresses of level 0 to level 3 entries read, respectively, and register PTWAddressValid is a bitmask indicating which address registers contain valid data: for example, the value 0xe indicates that PTWAddressL1-PTWAddressL3 are valid but PTWAddressL0 is not. Registers PTWValueL0-PTWValueL3 contain entry values read at level 0 to level 3. Register PTWInput contains the input address that starts a walk and Register PTWOutput contains the result address (valid only if the page table walk completes). Register PTWValueValid is a bitmask indicating which value registers contain valid data: bits 0-3 indicate PTWValueL0-PTWValueL3, respectively, bit 4 indicates PTWBase, bit 5 indicates PTWInput and bit 6 indicates PTWOutput.
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.
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 Cortex-A57MPx4 is available OVP_Model_Specific_Information_arm_Cortex-A57MPx4.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: 0xb7
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 44
master DATA 44
master GICRegisters 32

SystemC Signal Ports (Net Ports)


Port Type Name Description
SPI32 input
SPI33 input
SPI34 input
SPI35 input
SPI36 input
SPI37 input
SPI38 input
SPI39 input
SPI40 input
SPI41 input
SPI42 input
SPI43 input
SPI44 input
SPI45 input
SPI46 input
SPI47 input
SPI48 input
SPI49 input
SPI50 input
SPI51 input
SPI52 input
SPI53 input
SPI54 input
SPI55 input
SPI56 input
SPI57 input
SPI58 input
SPI59 input
SPI60 input
SPI61 input
SPI62 input
SPI63 input
SPI64 input
SPI65 input
SPI66 input
SPI67 input
SPI68 input
SPI69 input
SPI70 input
SPI71 input
SPI72 input
SPI73 input
SPI74 input
SPI75 input
SPI76 input
SPI77 input
SPI78 input
SPI79 input
SPI80 input
SPI81 input
SPI82 input
SPI83 input
SPI84 input
SPI85 input
SPI86 input
SPI87 input
SPI88 input
SPI89 input
SPI90 input
SPI91 input
SPI92 input
SPI93 input
SPI94 input
SPI95 input
SPIVector input
periphReset input
GICCDISABLE input
EVENTI input
EVENTO output
PPI16_CPU0 input
PPI17_CPU0 input
PPI18_CPU0 input
PPI19_CPU0 input
PPI20_CPU0 input
PPI21_CPU0 input
PPI22_CPU0 input
PPI23_CPU0 input
PPI24_CPU0 input
PPI25_CPU0 input
PPI26_CPU0 input
PPI27_CPU0 input
PPI28_CPU0 input
PPI29_CPU0 input
PPI30_CPU0 input
PPI31_CPU0 input
CNTVIRQ_CPU0 output
CNTPSIRQ_CPU0 output
CNTPNSIRQ_CPU0 output
CNTPHPIRQ_CPU0 output
IRQOUT_CPU0 output
FIQOUT_CPU0 output
CLUSTERIDAFF1 input
CLUSTERIDAFF2 input
VINITHI_CPU0 input
CFGEND_CPU0 input
CFGTE_CPU0 input
reset_CPU0 input
fiq_CPU0 input
irq_CPU0 input
sei_CPU0 input
vfiq_CPU0 input
virq_CPU0 input
vsei_CPU0 input
AXI_SLVERR_CPU0 input
CP15SDISABLE_CPU0 input
PPI16_CPU1 input
PPI17_CPU1 input
PPI18_CPU1 input
PPI19_CPU1 input
PPI20_CPU1 input
PPI21_CPU1 input
PPI22_CPU1 input
PPI23_CPU1 input
PPI24_CPU1 input
PPI25_CPU1 input
PPI26_CPU1 input
PPI27_CPU1 input
PPI28_CPU1 input
PPI29_CPU1 input
PPI30_CPU1 input
PPI31_CPU1 input
CNTVIRQ_CPU1 output
CNTPSIRQ_CPU1 output
CNTPNSIRQ_CPU1 output
CNTPHPIRQ_CPU1 output
IRQOUT_CPU1 output
FIQOUT_CPU1 output
VINITHI_CPU1 input
CFGEND_CPU1 input
CFGTE_CPU1 input
reset_CPU1 input
fiq_CPU1 input
irq_CPU1 input
sei_CPU1 input
vfiq_CPU1 input
virq_CPU1 input
vsei_CPU1 input
AXI_SLVERR_CPU1 input
CP15SDISABLE_CPU1 input
PPI16_CPU2 input
PPI17_CPU2 input
PPI18_CPU2 input
PPI19_CPU2 input
PPI20_CPU2 input
PPI21_CPU2 input
PPI22_CPU2 input
PPI23_CPU2 input
PPI24_CPU2 input
PPI25_CPU2 input
PPI26_CPU2 input
PPI27_CPU2 input
PPI28_CPU2 input
PPI29_CPU2 input
PPI30_CPU2 input
PPI31_CPU2 input
CNTVIRQ_CPU2 output
CNTPSIRQ_CPU2 output
CNTPNSIRQ_CPU2 output
CNTPHPIRQ_CPU2 output
IRQOUT_CPU2 output
FIQOUT_CPU2 output
VINITHI_CPU2 input
CFGEND_CPU2 input
CFGTE_CPU2 input
reset_CPU2 input
fiq_CPU2 input
irq_CPU2 input
sei_CPU2 input
vfiq_CPU2 input
virq_CPU2 input
vsei_CPU2 input
AXI_SLVERR_CPU2 input
CP15SDISABLE_CPU2 input
PPI16_CPU3 input
PPI17_CPU3 input
PPI18_CPU3 input
PPI19_CPU3 input
PPI20_CPU3 input
PPI21_CPU3 input
PPI22_CPU3 input
PPI23_CPU3 input
PPI24_CPU3 input
PPI25_CPU3 input
PPI26_CPU3 input
PPI27_CPU3 input
PPI28_CPU3 input
PPI29_CPU3 input
PPI30_CPU3 input
PPI31_CPU3 input
CNTVIRQ_CPU3 output
CNTPSIRQ_CPU3 output
CNTPNSIRQ_CPU3 output
CNTPHPIRQ_CPU3 output
IRQOUT_CPU3 output
FIQOUT_CPU3 output
VINITHI_CPU3 input
CFGEND_CPU3 input
CFGTE_CPU3 input
reset_CPU3 input
fiq_CPU3 input
irq_CPU3 input
sei_CPU3 input
vfiq_CPU3 input
virq_CPU3 input
vsei_CPU3 input
AXI_SLVERR_CPU3 input
CP15SDISABLE_CPU3 input

No FIFO Ports in Cortex-A57MPx4.


Exceptions


Name Code Description
Reset 0
Undefined 1
SupervisorCall 2
SecureMonitorCall 3
HypervisorCall 4
PrefetchAbort 5
DataAbort 6
HypervisorTrap 7
IRQ 8
FIQ 9
IllegalState 10
MisalignedPC 11
MisalignedSP 12
SError 13

Execution Modes


Mode Code Description
EL0t 0
EL1t 4
EL1h 5
EL2t 8
EL2h 9
EL3t 12
EL3h 13
User 16
FIQ 17
IRQ 18
Supervisor 19
Monitor 22
Abort 23
Hypervisor 26
Undefined 27
System 31

More Detailed Information

The Cortex-A57MPx4 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_Cortex-A57MPx4.pdf.

Other Sites/Pages with similar information

Information on the Cortex-A57MPx4 OVP Fast Processor Model can also be found on other web sites:
www.fast-core-models.org has a page on the ARM Cortex-A57MPx4
www.fast-iss-model.org has a page on the ARM Cortex-A57MPx4
www.cpu-model-emulator.com has a page on the ARM Cortex-A57MPx4
www.embedded-processor-models.org has a page on the ARM Cortex-A57MPx4
www.systemc-cpu-models.org has a page on the ARM Cortex-A57MPx4
www.imperas.com has more information on the model library