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

This section describes processor configuration parameters. See Table 4.29.

This section describes memory configuration parameters. See Table 4.30.

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 allowing the model to run faster.

Compare this to the effect of setting cpu[n].l2dcache-size_bytes = 0, which is to simulate a CPU 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.

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

Each cache block in the system is configured using the parameters listed in Table 4.32, 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 core. 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.

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

You can describe non-legal 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.12 and Figure 4.13 for examples of CPU-cache architecture configurations.

cpu0.cache-unification_level=2
cpu0.l2dcache-size_bytes=32768
cpu0.l2dcache-shared_key=1
cpu1.cache-unification_level=2
cpu1.l2dcache-size_bytes=32768
cpu1.l2dcache-shared_key=1

cpu0.cache-unification_level=2
cpu0.l2dcache-size_bytes=32768
cpu0.l2dcache-shared_key=1
cpu0.l3dcache-size_bytes=65536
cpu0.l3dcache-shared_key=2
cpu1.cache-unification_level=1
cpu1.l2dcache-size_bytes=32768
cpu1.l2dcache-shared_key=1
cpu1.l3dcache-size_bytes=65536
cpu1.l3dcache-shared_key=2
cpu2.cache-unification_level=2
cpu2.l2dcache-size_bytes=65536
cpu2.l2dcache-shared_key=2

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

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

Semihosting is a method of target software running on the model to communicate with the host environment. This model allows 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 core in the processor. See Table 4.35.

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

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