4.14.3. Parameters

In the platform models, configuration parameters are located in the parameter hierarchy at cluster.parameter_name. There are a number of other parameters that adjust the behavior of external platform components on the Versatile™ Express (VE) system board. These are:

Multiprocessor configuration

You can configure this model as a multiprocessor, so there are separate groups of configuration parameters for each processor in the system. In cases where fewer processors than the maximum number possible are instantiated, the parameters from cpu0 are always used first. See Table 4.34.

Table 4.34. Multiprocessing parameters

cluster_idValue for Cluster ID that is available to target programs in MPIDR.0
multiprocessor_extensionsEnable the instruction set changes introduced with the ARMv7 Multiprocessor Extensions.true
num_coresNumber of processors implemented. To instantiate more than one processor, set parameter multiprocessor_extensions.1
vmsa.cachetlb_broadcastEnable broadcasting of cache and TLB maintenance operations that apply to the inner shared domain.true
cpu[n].SMPnAMPPlace this processor inside the inner shared domain, and participate in the coherency protocol that arranges inner cache coherency among other processors in the domain.false

General processor configuration

This section describes processor configuration parameters. See Table 4.35.

Table 4.35. Processor configuration parameters

auxilliary_feature_register0Value for AFR0 ID register0
cpuIDValue for main processor ID register0x411fc081
dic-spi_countNumber of shared peripheral interrupts implemented.64
dtcm0_baseDTCM base address at reset0
dtcm0_enableEnable DTCM at resetfalse
dtcm0_sizeDTCM size in KB32
FILTERENEnable filtering of accesses between master bus ports. This is usually not used inside a VE system and should be left false.false
FILTERENDEnd of region filtered to pvbus_m1. Values must be aligned to a 1MB boundary.0
FILTERSTARTStart of region filtered to pvbus_m1. Values must be aligned to a 1MB boundary.0
implements_ple_like_a8Add support for the PLE from Cortex-A8false
IS_VALIDATION[a]Reserved. Enables A9-validation-like trickbox-coprocessor, which is only usable in validation platform model.false
itcm0_baseITCM base address at reset0x40000000
itcm0_enableEnable ITCM at resetfalse
itcm0_sizeITCM size in KB32
PERIPHBASE[b]Base address of MP “private” peripherals (WatchdogTimers, GIC) (bits 31:13 used).0x13080000
siliconIDValue for Auxilliary ID register0x41000000
CFGSDISABLEDisables access to some registers in the internal interrupt controller peripheral.false
implements_virtualizationImplement the Virtualization extension in this processor. When set, this also enables LPAE.false
implements_lpaeImplement the Large Physical Address extension in this processor.false
use_Cortex-A15_peripheralsChanges the layout of the internal peripheral memory map to mimic that of the Cortex-A15. See Internal peripherals.false
delayed_CP15_operationsDelay the functional effect of CP15 operations. See Delayed operation of CP15 instructions.false
take_ccfail_undefTake undefined exceptions even if the instruction failed its condition codes check. See An undefined instruction failed its condition code check.false
low_latency_modeRun only a single instruction between checks for IRQ and other events. This ensures that when the platform raises an interrupt, the exception vector is taken immediately, but it involves a considerable penalty in performance.false

[a] IS_VALIDATION is not exposed in the VE platform model, and fixed as false.

[b] PERIPHBASE is not exposed in the VEplatform model, and fixed as 0x2C000000.

Memory configuration

This section describes memory configuration parameters. See Table 4.36.

Table 4.36. Memory configuration parameters

vmsa.implements_fcseSupport fcse in this processorfalse
vmsa.infinite_write_bufferEnable infinite write-buffer. See Infinite write buffer.false
vmsa.write_buffer_delayElapsed time between natural buffer drains. See Infinite write buffer.1000
vmsa.delayed_read_bufferEnable deferred read values in conjunction with use_IR. See Memory operation reordering.false
vmsa.cache_incoherence_checkEnable the check for cache incoherence. See Cache incoherence check.false
vmsa.memory_marking_checkEnable the check for inconsistent memory marking in the TLB. See Memory marking check.false
vmsa.instruction_tlb_lockable_entriesNumber of lockable entries in instruction TLB32
vmsa.instruction_tlb_sizeTotal number of entries in instruction TLB32
vmsa.main_tlb_lockable_entriesNumber of lockable entries in data or unified TLB32
vmsa.main_tlb_sizeTotal number of entries in data or unified TLB32
vmsa.separate_tlbsSeparate ITLB and DTLB. If the TLB is unified, its size is defined by parameter vmsa.main_tlb_size.true
vmsa.tlb_prefetchEnables aggressive pre-fetching into the TLB. See Aggressively pre-fetching TLB.false
vmsa.implements_outer_shareableDistinguish between inner shareable and outer shareable memory access types. Outer shareable is implemented as Non Cacheable.true
vmsa.access_flags_hardware_managementEnable support for the hardware management of the Access Flag in the pagetables.true
dcache-state_modelledAllow line allocation in D-side caches at all levelstrue
icache-state_modelledAllow line allocation in I-side caches at all levels. Unified caches allocate lines only if these parameters are enabled at both I-side and D-side.true

The [d|i]cache-state_modelled parameters control the way that caches are simulated. When switched on, the default mode, all cache behaviors and maintenance operations are modeled fully.

If false, the cache is still present in the programmer’s view of the processor but in the simulated implementation there are no memory lines associated with the cache at this level. The programmer-view effect of this is as though the cache cleans and invalidates any line as soon as it is loaded, and can never become incoherent with its backing memory. Although this is an architecturally legal behavior, it is not realistic to any current hardware and is less likely to expose problems in target software. It can, however, be useful when debugging problems that are suspected to be related to cache maintenance, and also has the side effect of permitting the model to run faster.

Compare this to the effect of setting cpu[n].l2dcache-size_bytes = 0, which is to simulate a processor that contains only Level 1 caches. In this case, the ID code registers do not describe a Level 2 cache. Level 2 is entirely absent from the processor.

Cache geometry configuration

You can configure the multiprocessor with up to four levels of cache. The cache layout is not required to be symmetrical for each processor in the multiprocessor, so the parameters listed in Table 4.37 are repeated in groups cpu0-cpu3 corresponding to the view for each processor of the memory hierarchy.

Table 4.37. General cache configuration parameters

cpu[n].cache-coherency_level1-based-Level of cache coherency. A value of 2 means that the L2 caches, and all subsequent levels, are coherent.2
cpu[n].cache-unification_level1-based-Level of cache unification. A value of 2 means that the L2 caches, and all subsequent levels, are unified.2
cpu[n].cache-outer_levelLevel at which outer cache attributes start to be used. L1 caches always uses inner attributes. A value of 2 means that the L2 caches, and all subsequent levels, use outer attributes.2

Each cache block in the system is configured using the parameters listed in Table 4.38, which are repeated for groups cpu0-cpu3, and within each group in caches l1icache, l1dcache-l4icache, l4dcache.

The number and type of cache blocks are active depending on the unification level of each processor. Before the unification level, caches are separate on the instruction and data sides, and both sets of parameters are used. After the unification level, the data and instruction sides are unified, and the single cache block is described using the data side parameters only.

Table 4.38. Cache block configuration parameters

cpu[n].[cache]-size_bytesZero if the cache is not present, otherwise the total size in bytes of the cache. Must be divisible by the line length and associativity, and represent a number of cache sets not greater than 32768.32768
cpu[n].[cache]-linelength_bytesLength of each cache line. Must be 32 or 64.32
cpu[n].[cache]-associativityAssociativity of this cache. Must be between 1 and 1024.4
cpu[n].[cache]-read_allocateSupport allocate-on-read in this cachetrue
cpu[n].[cache]-write_allocate[a]Support allocate-on-write in this cachetrue
cpu[n].[cache]-write_back[a]Support write-back in this cachetrue
cpu[n].[cache]-write_through[a]Support write-through in this cachetrue
cpu[n].[cache]-treat_invalidate_as_clean[a]Always clean dirty cache lines before invalidating them. See Other checks.false
cpu[n].[cache]-shared_keyIf nonzero, mark this cache as being shared with other processors.0

[a] This parameter is not applicable to instruction-side caches.

The parameters for each processor describe the view for that processor of the memory hierarchy. If more than one processor has access to the same cache unit, for example, a shared Level 2 cache, then:

  • the cache must be described with all the same parameter settings in every case

  • all caches downstream of a shared cache must also be shared, and in the same order for every observer

  • the [cache]-shared_key parameter is set to an arbitrary nonzero value. Any cache in the system that has this value is considered to be one cache block.

You can describe nonlegal cache layouts using the shared_key mechanism. Not all bad cases can be easily detected during initialization, so take care to ensure correct cache configuration. The model might behave erratically if the cache layout cannot be rationalized.

See Figure 4.14 and Figure 4.15 for examples of processor-cache architecture configurations.

Figure 4.14. Processor-cache architecture configuration - Example 1

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.


Figure 4.15. Processor-cache architecture configuration - Example 2

To view this graphic, your browser must support the SVG format. Either install a browser with native support, or install an appropriate plugin such as Adobe SVG Viewer.



In the view of CPU2, the shared cache block marked L3U$ is at Level 2 in the memory system hierarchy.

Debug architecture configuration

The ARMv7 Debug architecture contains a number of optional features. The parameters listed in Table 4.39 control which of these features are implemented by the model.

Table 4.39. Debug architecture configuration parameters

implements_OSSaveAndRestoreAdd support for the OS Save and Restore mechanism implemented by DBGOSSRR and other registers.true
DBGOSLOCKINITInitial value for the Locked bit in DBGOSLSR. When this bit is set, software access to debug registers is restricted.0x1
implements_secure_user_halting_debugPermit debug events in Secure User mode when invasive debug is not permitted in Secure privileged modes. (Deprecated in ARM v7.)false
DBGPIDValue for CP14 DBGPID registers0x8000bb000
DBGCIDValue for CP14 DBGCID registers0x0
DBGDSCCR_maskImplemented bits of DBGDSCCR0x7
cpu[n].DBGDRARValue for Debug ROM address register0x0
cpu[n].DBGSRARValue for Debug Self address register0x0

Processor configuration

These parameters are repeated in groups cpu0-cpu3 for each processor in the multiprocessor. See Table 4.40.

Table 4.40. Processor configuration parameters

cpu[n].CFGEND0Starts the processor in big endian BE8 modefalse
cpu[n].CFGNMFISets the NMFI bit in the System Control Register (SCTLR) that prevents the FIQ interrupt from being masked in APSR.false
cpu[n].CFGTEStarts the processor in T32 modefalse
cpu[n].CP15SDISABLEDisables access to some CP15 registersfalse
cpu[n].VINITHIStarts the processor with high vectors enabled, the vector base address is 0xFFFF0000false
cpu[n].implements_neonSupport NEON in this processortrue
cpu[n].implements_thumbEESupport T32EE in this processortrue
cpu[n].implements_trustzoneSupport TrustZone in this processortrue
cpu[n].implements_vfpSupport VFP in this processortrue
cpu[n].fpsID Value for Floating-point System ID Register0x41033091
cpu[n].implements_vfpd16-d31If VFP is implemented, support 32 double-precision registers. Otherwise 16 are supported. If NEON is implemented, 32 registers are always supported and this parameter is ignored.true
cpu[n].implements_vfp_short_vectorsEnable support for vfp short vector operations, as indicated by MVFR0[27:24]true
cpu[n].implements_fused_macImplement the vfp fused multiply accumulate operationsfalse
cpu[n].implements_sdiv_udivImplement the integer divide operationsfalse
cpu[n].vfp-enable_at_resetVFP registers are enabled without a requirement to write the corresponding access enable bits firstfalse
cpu[n].use_IREnable operation reordering in conjunction with delayed_read_buffer. See Memory operation reordering.0

Semihosting configuration

Semihosting is a method of target software running on the model to communicate with the host environment. This model permits the target C library to access I/O facilities of the host computer; file system, keyboard input, clock and so on. For more information see the RealView Compilation Tools Developer Guide.

These parameters are repeated in groups cpu0-cpu3 for each processor in the multiprocessor. See Table 4.41.

Table 4.41. Processor configuration parameters

cpu[n].semihosting-ARM_SVCA32 SVC number to be treated as a semihosted call0x123456
cpu[n].semihosting-Thumb_SVCT32 SVC number to be treated as a semihosted call0xab
cpu[n].semihosting-cmd_lineProgram name and arguments to be passed as argc, argv to target programs using the semihosted c library. 
cpu[n].semihosting-enableEnable semihosting of SVC instructionstrue
cpu[n].semihosting-heap_baseVirtual address of heap base0x00000000
cpu[n].semihosting-heap_limitVirtual address of top of heap0x0f000000
cpu[n].semihosting-stack_baseVirtual address of base of descending stack0x10000000
cpu[n].semihosting-stack_limitVirtual address of stack limit0x0f000000

Message configuration

The parameters listed in Table 4.42 control how warning and error messages from the architectural checkers are generated.

Table 4.42. Message severity levels

messages.break_warning_levelThe simulation stops in the debugger after emitting a message at this level or higher.5
messages.ignore_warning_levelMessages below this level are ignored and not printed.1
messages.suppress_repeated_messages The simulation does not emit more than one copy of a message when it is generated from a given point in the target program.true
messages.output_fileThe path[a] of the file to which messages are written. If blank, messages are sent to stderr. 

[a] The format of the string follows the normal file path conventions for the host platform. File paths without a leading root are written into the current working directory, which might vary.

Except for fatal errors, the severity level of each message can be reconfigured in parameters messages.severity_level_[*], permitting you to concentrate only on those warnings that are appropriate to your task. See Table 4.43.

Table 4.43. Message configuration parameters

0Minor WarningSuspect, but plausibly correct
1WarningA likely bug
2Severe WarningTechnically legal, but believed certain to be a bug
3ErrorA definite architectural violation
4Severe ErrorTarget code unlikely to be able to recover
5FatalFrom which the simulation is unable to continue

Copyright © 2008-2013 ARM. All rights reserved.ARM DUI 0423O